JSF 正开始凭借其 Java Web 标准的地位主导 Java Web 应用程序市场随着更多的开发人员受托使用 JSF 作为基础来架构应用程序他们发现 JSF 的核心规范中清楚地说明 JSF 不是为成为一个完整的 Web 应用程序框架而设计的相反它提供一个健壮的事件驱动的 API 和 UI 组件库用于构建更复杂的应用程序框架
我在寻找用于弥补 JSF 的组件驱动架构的扩展时发现 Shale 和 Struts 都有不足之处我排除了 Struts 因为它将 JSF 看作是面向更大范围的设计而 Shale 似乎更靠近一些它基本上是基于 JSF但是 对此我持保留意见相反JBoss Seam 是一个全面的应用程序框架它构建在 JSF 的基础上但是并没有损害它的核心目标
寻找 Seam
刚刚阅读到关于 JBoss Seam 的文章的第一页我就知道 Seam 正是我要找的项目Seam 的开发人员尤其是 Gavin King在经过足够多的实际的开发之后知道一个 Web 应用程序框架必须从一开始就攻破难题包括上下文状态管理RESTful 和用户友好的 URLAjax remoting适当的异常处理和约定优于配置令 Java 开发人员欣喜的是Seam 可以满足所有这些需求甚至可以满足更多需求如果您正使用 JSF并且还没听说过 Seam那么我强烈建议您看看 Seam 的参考文档Seam 附带的手册就是最好的资料!
尽管 Seam 显然非常适合作为 JSF 的补充但是在激烈的竞争环境中它遭到了一定程度的轻视当今市场中充斥着各种各样的 Web 应用程序框架 —— 包括 Shale 和 Struts 新来者往往不受重视Seam 还没有在主流行列站稳脚跟 Seam 没有很快流行的另一个原因是关于这种框架的某些流言使 Java 开发人员没能认识到它的直接优点
我要粉碎的一个流言是Seam 只有和 EJB 一起使用时才有用或者说在使用 Seam 开发应用程序时需要一个 EJB 容器实际上Seam 的文档清楚地驳斥了这种误解Seam 并不要求组件是 EJB甚至在没有兼容 EJB 的容器时也能使用 如果说只有在使用 EJB 的同时才能使用 Seam那么无异于说只有在使用 Hibernate 的同时才能使用 Spring虽然这两对都有很强的互补性但是每一对的两者之间都不是相互依赖的
对 EJB 的考虑
正如我将要解释的那样Seam 通过一些有价值的 hook 和组件管理进程 扩展默认 JSF 生命周期还可以完全独立于 EJB 使用 Seam但是要记住和 EJB 一样Seam 依赖于 JDK 注释元数据进行组件声明因此使用 Seam 时还需要同时使用兼容 Java 的 JVM图 显示了一个 Seam POJO 实现的应用程序堆栈
图 一个 Seam POJO 应用程序堆栈
实际上即使完全不引用 EJB jar 或描述符文件也可以使用 Seam 的很多功能当和 POJO 一起使用 Seam 时该框架保留对组件实例化的完全控制并且不要求任何专门的配置Seam 负责大多数 Java 注释处理而不需要依赖于 EJB 中的任何机制的确 依赖于 EJB 容器的一组有限的注释则是专用于那个环境的在某些情况下将 Seam 集成到一个没有 EJB 耦合的 IT 投资中可以获得更好的成本效益如何使用 Seam 视个人偏好而定
配置并使用
如今有那么多种 Java 框架每天只有有限的那么多小时显然如果 Seam 难于集成的话它就无立足之地幸运的是将 Seam 添加到项目中很简单因为 JSF 生命周期仍然是 Seam 应用程序的中心部分所以不需要经历一个再训练时期只需添加 个 jar 文件注册一个 servlet 监听器和一个 JSF phase 监听器最后再加上一个空白的 Java 属性文件完成这些设置后就可以一次性地将本地 JSF 应用程序转移到 Seam 管理的 bean 上
要开始使用 Seam首先需要将所需的 jar 文件添加到项目中如果您当前不是使用 Hibernate或者还没有升级到最新的版本那么在设置时需要执行一个额外的步骤这里需要包含来自 Hibernate distribution 的 jar以及它的众多的依赖项Seam 还使用 Hibernate 注释用于数据验证所以除了主 Hibernate jar 之外还必须包括那个扩展 jar需要的 Seam 发行版中的库有 jbossseamjar 和 jbossseamuijar以及两个支持库Javassist(用于 Java 的加载时反射系统)和 Java Persistence API图 中的项目树说明了一个 Seam 项目中的 jar 集合该图中显示的大多数附加库支持 JSF 的 MyFaces 实现
图 Seam 项目中的 jar 库
……
