- 浏览: 634167 次
- 性别:
- 来自: 北京
最新评论
-
2047699523:
java hibernate demo使用实例教程源代码下载: ...
hibernate延迟加载的原理与实现 -
在世界的中心呼喚愛:
hantsy 写道这种lazy的解释只对了一半,按java p ...
hibernate延迟加载的原理与实现 -
moguicy:
看了下时间,不是楼主是否还在开发
【翻译】Wicket启示录——理论与实践(一) -
xfan0828:
"最后但并不是最不重要的一点就是" BZ, ...
【翻译】深入浅出 EJB3.1(上) -
doudou87323:
十分感谢,正在学习中,受益匪浅
【翻译】深入浅出 EJB3.1(上)
本节主要包括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}
评论
发表评论
-
【翻译】深入浅出 EJB3.1(下)
2009-05-07 23:37 8813Global JNDI names( 统一的 全局 ... -
【翻译】深入浅出 EJB3.1(上)
2009-05-06 20:59 11007终于有空将EJB3.1的最新文章与大家分享,原文请看: ht ... -
【翻译】Java EE 6体系结构的变革
2009-02-09 10:01 4448又看到 Reza 同学为 -
【翻译】Java EE 6体系结构的变革(完)
2009-02-09 10:00 6411JSF 2.0 尽 ... -
垃圾收集器是一个“宝贝收藏家”?
2008-11-25 23:58 2996原文请看:http://java.dzone.com/ar ... -
深入理解JBoss Cache3.0——Naga
2008-11-12 09:12 9657原文请看: http://java.dzone.com/ ... -
【翻译】Rod Johnson——关于当选JCP执行委员会的之言片语
2008-11-03 10:42 3138SpringSource 在上月底被宣布被加入 JCP ... -
【翻译】EJB3.1真的来了吗?EJB3.1系列文章(五) 终章
2008-10-16 14:37 9094历时9 个多月的EJB3.1 系列文章终于要划上圆满的句 ... -
【翻译】Rod Johnson——平衡的质疑:Spring维护策略的再次调整(完)
2008-10-09 09:33 3970不管你承不承认,Spring实际上已经是实事上JAVA企业开 ... -
【云计算专家Joseph Ottinger系列】应用服务器本质论
2008-09-08 08:58 3425原文请看: http://www.t ... -
Spring破坏了JEE规范吗?
2008-09-02 13:33 4046[TTS 编辑注:这是 TTS 论坛上的原帖。我现在把它 ... -
【翻译】spring配置全书(下)——附PDF完整版下载
2008-07-14 12:30 10759JMS 命名空间简介 Schema URI ... -
【翻译】spring配置全书(上)
2008-07-07 23:11 8878作者简介: Craig Walls 是 Texa ... -
【翻译】EJB3.1真的来了吗?EJB3.1系列文章(四)
2008-06-18 23:10 38151前言 Raza 同学终于又出 EJB3.1 文章了 ... -
【翻译】Rod Johnson——Spring的宣言:开源,开放(完)
2008-06-10 16:51 5562前言 这是本文的第二部分,里面提到并回答许多Spring用 ... -
【翻译】Rod Johnson——Spring的宣言:开源,开放
2008-06-06 13:06 6051原文地址: http://blog.sp ... -
【翻译】EJB3.1真的来了吗?EJB3.1系列文章(三)
2008-05-01 13:53 8728文本继续和大家分享EJB3.1特性,今天谈到的EJB Lite ... -
【Danny hui】运用抽象工厂模式自己动手写一个IoC
2008-04-23 16:34 6283本文的作者Danny hui似乎是TTS上的新人,我从Goog ... -
【翻译】Wicket启示录——理论与实践(三)完
2008-04-11 01:09 6183接下来,我们再看看EditContact类,把新建联系人的话和 ... -
【翻译】Wicket启示录——理论与实践(二)
2008-04-09 23:47 5824第二部分 实践 Application(应用程序) 与 ...
相关推荐
JSF是一种用于构建Java Web 应用程序的标准框架(是Java Community Process 规定的JSR-127标准)。JSF(Java Server Faces)技术为开发基于网络用户界面的Java开发者提供了标准的编程接口API以及标签库。就像Struts框架...
jsf实例 JSF学习 JSF jar包 JSF jsf实例 JSF学习 JSF jar包 JSFjsf实例 JSF学习 JSF jar包 JSF jsf实例 JSF学习 JSF jar包 JSF
jsf 分页 jsf 分页 jsf 分页 jsf 分页
《JSF_实战》非常好的JSF学习书《JSF_实战》非常好的JSF学习书《JSF_实战》非常好的JSF学习书《JSF_实战》非常好的JSF学习书《JSF_实战》非常好的JSF学习书《JSF_实战》非常好的JSF学习书《JSF_实战》非常好的JSF...
介绍JSF框架中使用的一些设计模式以及其应用。
================================= JSF开发必备JAR ================================= <br>《JSF入门简单中文版》开篇提到JSF开发需要的jar,' 但是按其中提供的方法: <br>jstl.jar 与 ...
JSF中文教程JSF中文教程JSF中文教程JSF中文教程
主要讲述JSF的工作方式 JSF的工作方式 JSF架构 JSF模型 JSF事件类型
jsf入门小列子和 jsf与Tiles结合小列子, 可以帮助初学都快迅入门
一个关于JSF与hibernate整合的登陆小项目 ,适合初学者
第一个JSF程序,初学JSF者必备,jsf架包 jsf实例
JSF开发介绍JSF开发介绍JSF开发介绍JSF开发介绍JSF开发介绍JSF开发介绍JSF开发介绍JSF开发介绍JSF开发介绍
JSF的学习入门知识教程,里面有例子还有各个标签的使用及属性介绍
自己写的JSF文件上传项目,可以最大支持最大1.99G文件 需要的jar包需奥自己加 附:jar目录截图
jsf1.2 core jsf jsf核心
关于jsf+ejb+jpa整合,光盘上代码这样写的。
jsf 中文文档jsf 中文文档jsf 中文文档jsf 中文文档
jsf 视频 java faces jsf 视频 java faces jsf 视频 java faces
JSF入门教程 JSF入门教程 JSF入门教程