【JSF专家Dennis Byrne】JSF反模式与陷井(二) 博客分类： 专家文章翻译 JSFBean.netXHTMLJSP
本节主要包括JSF的XML配置，线程安全等问题，是JSF开发人员不可多得的指导性文章。Dennis Byrne绝对是一位实战型JSF专家，不仅仅能对JSF规范提出不满，而且还对存在问题的JSF作一一解答。
正文:
盲目使用XML
JSF的XML配置文件就算没有几千行，一般也得个几百行了。我曾经见过一个这样的项目：他们的“联系我们”这个页面充斥在几乎所有的单独的navigation-rule中：
<navigation-rule> <from-view-id>/home.xhtml</from-view-id> <navigation-case> <from-outcome>contact_us</from-outcome> <to-view-id>/contact.xhtml</to-view-id> </navigation-case> </navigation-rule> <navigation-rule> <from-view-id>/site_map.xhtml</from-view-id> <navigation-case> <from-outcome>contact_us</from-outcome> <to-view-id>/contact.xhtml</to-view-id> </navigation-case> </navigation-rule> <navigation-rule> <from-view-id>/about_us.xhtml</from-view-id> <navigation-case> <from-outcome>contact_us</from-outcome> <to-view-id>/contact.xhtml</to-view-id> </navigation-case> </navigation-rule> <!—下面还有很多……. -->
而现在仅仅只需要一个全局navigation-rule就可以搞定了：
<navigation-rule> <from-view-id>*</from-view-id> <navigation-case> <from-outcome>contact_us</from-outcome> <to-view-id>/contact.xhtml</to-view-id> </navigation-case> </navigation-rule>
XML地狱还远不止这些，还有很多运行期异常，我们来看几个例子：
<managed-bean>
<managed-bean-name>invalid</managed-bean-name>
<!-- misspelled class name throws ClassNotFoundException -->
<managed-bean-class>net.dbyrne.misspelled.Invalid</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
<managed-property>
<!-- one side of cyclical reference -->
<property-name>incorrect</property-name>
<value>#{incorrect}</value>
</managed-property>
</managed-bean>
<managed-bean>
<managed-bean-name>incorrect</managed-bean-name>
<managed-bean-class>net.dbyrne.validate.Incorrect</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
<managed-property>
<!-- other side of cyclical reference -->
<property-name>invalid</property-name>
<value>#{invalid}</value>
</managed-property>
</managed-bean>
心细一点，很快能看出这是一个依赖注入死循环！！！而根据JSF实现，如果发生这样情况应用程序启动时不会得到任何警告，但运行期肯定会抛异常。（注：如果使用Spring来故意这样配置的话，启动时就会报错，由此可见JSF的依赖注入还不是很成熟）。
再来看一个配置重名的情况：
<managed-bean>
<!-- first duplicate -->
<managed-bean-name>duplicate</managed-bean-name>
<managed-bean-class>
net.dbyrne.validate.FirstDuplicate
</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
<managed-bean> <!-- second duplicate -->
<managed-bean-name>duplicate</managed-bean-name>
<managed-bean-class>
net.dbyrne.validate.SecondDuplicate
</managed-bean-class>
<managed-bean-scope>application</managed-bean-scope>
</managed-bean>
这个问题JSF1.2已经修正了。但使用JSF的仍然有不少是1.1版本。这让开发人员相当头痛了——调试难度相当大。大多数1.1的JSF实现版本都会忽略第一个重名的bean，而只是简单的调用第二个。（注：不光JSF，Struts2同样也存在这样的话，特别是数百行以上的XML配置文件，如果真有人不小心这么写了，出现的问题常常摸不到头脑，我已经遇到过两次，受有体会。）
再来看看最后一个例子：
<managed-bean>
<managed-bean-name>requestScopeManagedBean</managed-bean-name>
<managed-bean-class>
net.dbyrne.RequestScopeManagedBean
</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
<managed-bean>
<managed-bean-name>sessionScopeManagedBean</managed-bean-name>
<managed-bean-class>
net.dbyrne.SessionScopeManagedBean
</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
<managed-property>
<!-- throws runtime exception -->
<property-name>requestScopeManagedBean</property-name>
<value>#{requestScopeManagedBean}</value>
</managed-property>
</managed-bean>
乍一看，没什么嘛。但再请看看两个bean的作用域：一个是request，一个是session。JSF规定：如果一个受托管的bean的作用域必须小于其依赖注入的属性的作用域。也就是说上面的的这个例子sessionScopeManagedBean的作用域是session，而其一个注入的属性requestScopeManagedBean却是request，与JSF规范不符，运行期肯定出错。
大多数像这些配置上的缺陷是可以通过JUnit，JBossJSFUnit检测到的。当然，你还可以使用Seam或Shale的Annotation类库，从而避免XML问题。
线程安全
不是所有的代码都要考试线程安全问题。通过调用FacesContext.getCurrentInstance()返回的数据是线程内安全的，而且request或unscoped作用域所托管的bean也是安全的。但有些代码你就需要注意了，它们可能被多个线程同时访问。
现在我们拿PhaseListeners和Renderers举例。每一个PhaseListener生存周期都是application作用域并且为每一个request至少保持一个状态。组件实例(component)与Renderer实例之间是多对一的关系——相同类型的组件可以共享同一个Renderer实例。处在Session和application作用域的bean显然会不止一个线程访问。
标签一般是不需要考虑线程安全的，但你所运行的容器却可以将先前的标签实例重用。(注：这一点听去似乎有点可怕啊……)。因此将标签所涉及到的字段复位总是需要的。你可以随便使不使用Converter标签来保证线程安全。一个Converter标签的使用永远不会导致线程问题，组件会每次调用时帮你返回一个实例，请看下面代码：
<converter>
<converter-id>threadUnsafeConverter</converter-id>
<converter-class>net.dbyrne.ThreadUnsafeConverter</converter-class>
</converter>
<h:inputText value="#{managedBean.value}" >
<!-- 这里使用的是converter标签 -->
<f:converter converterId="threadUnsafeConverter" >
</h:inputText>
如果使用的是标签里的converter属性，那可能就没这么幸运了。这个时候，很有可能这个实例会同时被多个request访问到。
<managed-bean>
<managed-bean-name>threadUnsafeConverter</managed-bean-name>
<managed-bean-class>net.dbyrne.ThreadUnsafeConverter</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
<!-- 这里使用的是converter属性 -->
<h:inputText value="#{managedBean.value}" converter="#{threadUnsafeConverter}" />
验证标签存在同样的问题。
迁徙到Facelets的挑战：自定义标签是否应该与行为绑定？？？
Java开发者们使用自己的JSP标签有些年头了。JSF继承发扬JSP标签是因为JSF的默认视图就是JSP！！！JSF触发是由JSP标签调用set方法生效的。当调用标签时，标签上的属性值将传递到其映射的UI组件上去。
public class WidgetTag extends UIComponentELTag{
private String styleClass = "default_class";
private String title;
public String getComponentType() {
return "net.dbyrne.widget";
}
public String getRendererType() {
return "net.dbyrne.widget";
}
public void setStyleClass(String styleClass) {
this.styleClass = styleClass;
}
public void setTitle(String title) {
this.title = title;
}
public void release() {
super.release();
styleClass = null;
title = null;
}
protected void setProperties(UIComponent component) {
super.setProperties(component);
Widget span = (Widget) component;
span.setStyleClass(styleClass);
span.setTitle(title == null ? "no title" : title);
FacesContext ctx = FacesContext.getCurrentInstance();
Map sessionMap = ctx.getExternalContext().getSessionMap();
span.setStyle((String) sessionMap.get("style"));
}
}
稍微有经验的JSF程序会注意到这段代码有点问题。styleClass字段默认设置成“default_style”，title字段依赖于三元运算符，还有一个组件值要通过父类来计算出来 (注意这里说的应该是release()方法) 。很遗憾，这个标签的实现与具体行为绑的死死的。但我现在要说的是，我不鼓励这种做法。当你使用类似于Facelets的可选视图技术后，组件绑定行为可以放弃不用了。我们在开发JSF组件的时候，一个重要的原则就是一标签只处理一个逻辑! Apache MyFaces的代码就是一个很好的例子。源文件有25个组件和25个标签，在构建期时，通过元数据就将它们生成好了，不包含任何行为。
得墨忒耳法则
在一次JavaOne大会上，Mathias需要借些钱。“Craig” Mathias说到：“我欠了Martin一瓶啤酒，能借我5美元吗？” 。于是Craig*让Mathias的从自己的钱包里瞎翻出5美元给了Martin。这时Craig说到：“Mathias，如果我把钱放在鞋子或钱包里的话，你也许可换种方式以从我这里借钱了。” Mathias接着说：“很好，我借钱的逻辑与你将钱放在哪里的逻辑是有关系的的。下次当我再向你借钱时，你只要关心钱在哪就行了。”Craig知道Mathias是个精明的家伙，他的这个建议立即使得这个借钱与给钱立即得到解藕了。这就是经典的得墨忒耳法则。
人人都知道没有当事人的允许，是不可以去翻别人的钱包。但很多开发人员却在开发时常常无法清醒的认识到这一点：
// highly sensitive to changes of the domain model
employee.getDepartment().getManager().getOffice().getAddress().getZip()
<!-- highly sensitive to changes of the domain model -->
#{employee.department.manager.office.address.zip}
缺少经验的程序员需要明白：上面的代码违背了面向对象的原则，随时会在其中某个地方不加判断而掉链子。但有一些人并没有认识到这么长的EL表达式也是相当糟糕的。由于使用了EL表达式，这段代码不会出现编译错误。那么MethodNotFoundErrors和NullPointerExceptions异常对类似于这样的视图来说就是家常便饭了。重构是很痛苦的，因为EL表达式本身是不是强类型的。当EL表达式要间接访问视图model多级属性时，还不如先封装一下，再调用：
<!-- encapsulated, insensitive to changes -->
#{employee.departmentalManagerOfficeZip}