Seam无缝集成：为JSF定做应用程序框架

1、.：.；JavaServer Faces (JSF) 是用于 Java Web 运用程序的第一个规范化的用户界面框架。而 Seam 是一个扩展 JSF 的强大的运用程序框架。在这个由三部分组成的新系列中的第一篇文章中，发现这两种框架之间的互补性。Dan Allen 引见了 Seam 对 JSF 生命周期的加强，包括上下文形状管理、 RESTful URL、Ajax remoting、适当的异常处置和商定优于配置。JSF 正开场凭仗其 Java Web 规范的位置主导 Java Web 运用程序市场。随着更多的开发人员受托运用 JSF 作为根底来架构运用程序，他们发现 JSF 的中心规范中清楚地

2、阐明： JSF 不是为成为一个完好的 Web 运用程序框架而设计的。相反，它提供一个强壮的、事件驱动的 API 和 UI 组件库，用于构建更复杂的运用程序框架。我在寻觅用于弥补 JSF 的组件驱动架构的扩展时，发现 Shale 和 Struts 2 都有缺乏之处。我排除了 Struts 2，由于它将 JSF 看作是面向更大范围的设计。而 Shale 似乎更接近一些，它根本上是基于 JSF，但是 对此我持保管意见。相反，JBoss Seam 是一个全面的运用程序框架，它构建在 JSF 的根底上，但是并没有损害它的中心目的。这个由三部分组成的系列将引见 Seam 运用程序框架，演示它的优点，并希望

3、使您置信它与 JSF 是开发 Java 企业运用程序的极好的组合。在阅读本系列之前，假设您想下载 Seam，那么请阅读 参考资料 一节。寻觅 Seam刚刚阅读到关于 JBoss Seam 的文章见 参考资料的第一页，我就知道 Seam 正是我要找的工程。Seam 的开发人员，尤其是 Gavin King，在经过足够多的、实践的开发之后，知道一个 Web 运用程序框架必需从一开场就攻破难题，包括上下文形状管理、RESTful 和用户友好的 URL、Ajax remoting、适当的异常处置和商定优于配置。令 Java 开发人员欣喜的是，Seam 可以满足一切这些需求，甚至可以满足更多需求。假设您

4、正运用 JSF，并且还没听说过 Seam，那么我剧烈建议您看看 Seam 的参考文档见 参考资料。Seam 附带的手册就是最好的资料！虽然 Seam 显然非常适宜作为 JSF 的补充，但是在猛烈的竞争环境中，它遭到了一定程度的轻视。当今市场中充斥着各种各样的 Web 运用程序框架 ? 包括 Shale 和 Struts 2，新来者往往不受注重，Seam 还没有在主流行列站稳脚跟。 Seam 没有很快流行的另一个缘由是关于这种框架的某些流言使 Java 开发人员没能认识到它的直接优点。我要粉碎的一个流言是：Seam 只需和 EJB 3 一同运用时才有用，或者说在运用 Seam 开发运用程序时需求

5、一个 EJB3 容器。实践上，Seam 的文档清楚地驳斥了这种误解：Seam 并不要求组件是 EJB，甚至在没有兼容 EJB 3.0 的容器时也能运用。 假设说只需在运用 EJB 3 的同时才干运用 Seam，那么无异于说只需在运用 Hibernate 的同时才干运用 Spring。虽然这两对都有很强的互补性，但是每一对的两者之间都不是相互依赖的。对 EJB3 的思索正如我将要解释的那样，Seam 经过一些有价值的 hook 和组件管理进程 扩展默许 JSF 生命周期。还可以完全独立于 EJB3 运用 Seam。但是要记住，和 EJB3 一样，Seam 依赖于 JDK 5 注释元数据进展组件声

6、明，因此运用 Seam 时，还需求同时运用兼容 Java 5 的 JVM。图 1 显示了一个 Seam POJO 实现的运用程序堆栈：图 1. 一个 Seam POJO 运用程序堆栈实践上，即使完全不援用 EJB 3 jar 或描画符文件，也可以运用 Seam 的很多功能。当和 POJO 一同运用 Seam 时，该框架保管对组件实例化的完全控制，并且不要求任何专门的配置。Seam 担任大多数 Java 5 注释处置，而不需求依赖于 EJB 3 中的任何机制。确实 依赖于 EJB3 容器的一组有限的注释那么是公用于那个环境的。在某些情况下，将 Seam 集成到一个没有 EJB 3 耦合的 IT

7、投资中可以获得更好的本钱效益。如何运用 Seam 视个人偏好而定。配置并运用如今有那么多种 Java 框架，每天只需有限的那么多小时，显然，假设 Seam 难于集成的话，它就无立足之地。侥幸的是，将 Seam 添加到工程中很简单。由于 JSF 生命周期依然是 Seam 运用程序的中心部分，所以不需求阅历一个再训练时期。只需添加 4 个 jar 文件，注册一个 servlet 监听器和一个 JSF phase 监听器，最后再加上一个空白的 Java 属性文件。完成这些设置后，就可以一次性地将本地 JSF 运用程序转移到 Seam 管理的 bean 上。要开场运用 Seam，首先需求将所需的 ja

8、r 文件添加到工程中。假设您当前不是运用 Hibernate，或者还没有晋级到最新的版本，那么在设置时需求执行一个额外的步骤。这里需求包含 Hibernate 3.2 distribution 的 jar，以及它的众多的依赖项。Seam 还运用 Hibernate 注释用于数据验证，所以除了主 Hibernate jar 之外，还必需包括那个扩展 jar。需求的 Seam 发行版中的库有 jboss-seam.jar 和 jboss-seam-ui.jar，以及两个支持库：Javassist用于 Java 的加载时反射系统和 Java Persistence API。图 2 中的工程树阐明了一

9、个 Seam 工程中的 jar 集合。该图中显示的大多数附加库支持 JSF 的 MyFaces 实现。图 2. Seam 工程中的 jar 库配置 Seam接下来的步骤是在 web.xml 文件中安装 servlet 监听器类。该监听器在部署运用程序时初始化 Seam。清单 1. Seam servlet 监听器配置 org.jboss.seam.servlet.SeamListener 接下来，将 JSF phase 监听器添加到 faces-config.xml 文件中，如清单 2 所示。该监听器将 Seam 集成到规范 JSF 生命周期中。图 3 大致描画了集成到这个生命周期中的 Sea

10、m 加强。清单 2. Seam phase 监听器配置 org.jboss.seam.jsf.SeamPhaseListener 最后，将一个空的 perties 文件放在类途径的根下，以便指示 Seam 进展加载，如清单 3 所示。这个空白文件被用作一个 JVM 类加载器优化，使 Seam 在类途径下更小的区域内搜索组件，从而大大减少加载时间。清单 3. Seam 属性文件# The mere divsence of this file triggers Seam to load# It can also be used to tune parameters on configurable

11、Seam components当然，在这种最小设置中，Seam 的很多特性是不可用的。以上阐明只是为了演示 Seam 很少涉足入门级运用。例如，Seam 包括一个 servlet 过滤器，该过滤器扩展 JSF 生命周期以外的 Seam 特性。 servlet 过滤器的用法包括与非 JSF 恳求集成，经过重定向传播 conversation，以及管理文件上传。请参阅 参考资料，看看 Seam 参考文档，其中讨论了用于控制附加功能的配置文件 ? 特别是 EJB3 集成。与 Seam 关联与典型的 JSF 配置过程相比，运用 Seam 开发受管 bean 非常容易。为了将 bean 暴露到 JSF

12、生命周期中，只需在类定义的上面添加一个简单的注释 Name。然后，Seam 会担任控制组件的可见性和生命周期。最妙的是，不需求在 faces-config.xml 文件中定义这个 bean。清单 4 显示了 Name 注释以及 DataModel、DataModelSelection、In、Out 和 Factory。这些注释使变量可以在视图模板和 Seam 组件之间双向流动。在 Seam 用语中，这个动作被称作双射bijection，即 bidirectional injection 的简称。当注出outject属性数据时，视图可以经过称号找到它。在 postback 或者组件初始化时，数据

13、被注入inject到一个组件中。后者是著名的控制反转inversion of control，IOC方式的一种实现，可用于衔接委托对象。传统 IOC 与 Seam 的双射之间的主要不同点在于，双射使长期作用域中的组件可以援用短期作用域中的组件。可以进展这种衔接是由于 Seam 在调用组件时而不是启动容器时解析依赖项。双射是有形状组件开发的根底。显然，清单 4 中的 POJO bean 只是简单地演示了 Seam 的用法。随着本系列讨论的继续，我将探求另外的方法来实现 Seam。清单 4. 一个典型的 Seam POJO beanName(addressManager) public class

14、 AddressManagerBean DataModel private List addresses; DataModelSelection Out( required = false ) private Address selectedAddress; Factory( value = addresses ) public void loadAddress() / logic to load addresses into this.addresses public String showDetail() / no work needs to be done to divpare the

15、selected address return /address.jspx; public String list() return /addresses.jspx; Spring 的注入为了运用由一个已有的 Spring 容器管理的效力层对象中的投资，需求将一切处置相关业务逻辑的 Spring bean 注入到 Seam 组件中。首先需求确保曾经配置了 Spring-JSF 集成，它由 Spring 框架附带的一个定制变量解析器进展处置见 参考资料。有了这座桥梁，Spring 与 Seam 的集成就很简单，只需运用 In Java 5 注释和一个值绑定表达式，以阐明 Seam 组件的哪些属性

16、应该接纳一个 Spring bean 的注入，如清单 5 所示。未来版本的 Seam 将包括用于 Spring 的一个定制的称号空间，以满足值绑定表达式的需求。清单 5. 注入一个 Spring beanName(addressManager) public class AddressManagerBean In(#addressService) private AddressService addressService; 这个例子设置支持运用以轻量级容器这里就是 Spring配置的无形状效力和数据访问DAO层。由于不需求 EJB3，所以部署的目的可以是任何根本的 servlet 容器。如今，

17、您对 Seam-JSF 实现有了一个初步的印象，接下来我将更深化地讨论我在运用 JSF 时遇到的挑战，以及 Seam 如何缓解这些挑战。再谈 JSF为了充分了解 Seam 为 JSF 带来了什么，就需求了解 JSF 与其他流行的基于 Web 的编程方法有何不同。JSF 是实现传统的 Model-View-Controller (MVC) 架构的一种 Web 框架。不同之处在于，它采用该方式的一种特别丰富的实现。与 Model 2 或者 Struts、WebWork 和 Spring MVC 之类的框架中运用的 “push-MVC 方法相比，JSF 中的 MVC 实现更接近于传统的 GUI 运用

18、程序。前面那些框架被归类为基于动作的action-based，而 JSF 那么属于基于组件模型 的新的框架家族中的一员。假设将基于动作的框架想象为运用 “push 模型，而将组件框架想象为运用 “pull 模型，那么这种区别就很容易了解了。组件框架中的控制器不是预先处置页面恳求在基于动作的框架中控制器就是这么做的，而是在恳求生命周期中作出退让，在视图中调用数据提供方法。此外，页面上的元素，即组件被绑定到事件，这些事件可以触发效力器端对象激活后的方法调用，从而导致重新显示一样的视图，或者转换到另一个页面。因此，组件框架也被归类为事件驱动的。组件框架笼统出用于事件通讯的底层恳求呼应协议。事件驱动方

19、法的优点是可以减少单个方法在呈现视图时需求预先做的任务。在组件框架中，UI 事件或解析的值绑定表达式直接导致方法调用。一个运用程序即使只到达中度成熟，它通常也需求在任何给定页面上运用很多不相关的活动。假设将对一切这些信息的管理全部放入一个动作或者一个动作链中，那么势必给维护带来极大的困扰。因此，开发人员经常发现他们的代码偏离了面向对象模型的轨道，反而堕入了过程编程模型的泥潭。相反，组件框架将这种任务隔离出来，更自然地加强了对象的角色和责任。Seam 与 JSF对于 JSF 和组件框架的根底曾经引见得差不多了。实践上 ? 很多 Java 开发人员最近发现 ? 转移到 JSF 并非总是一帆风顺。采

20、用组件模型会带来一些全新的问题，首要的一个问题是您通常需求试着使运用程序符合基于动作的 Web。很多时候，JSF 需求具有像基于动作的框架那样的行为，但是在规范 JSF 中这是不可行的，至少不为每个恳求运用 phase 监听器就不行。JSF 的其他主要缺陷还包括对 会话的依赖过重尤其是在一序列的页面之间传播数据时，简陋的异常处置，短少书签支持，以及太多的 XML 配置。经过与 JSF 自然地集成，同时参与 JSF 规范委员会放弃的或者忽略掉的新功能，Seam 处理了很多这样的问题。Seam 的框架鼓励运用紧凑的、易读的、可重用的代码，并且防止了一切为处理上述问题而经常参与的 “粘连glue 逻

21、辑。图 3 涵盖了 JSF 生命周期中用于简化运用程序代码的大多数 Seam 扩展点：图 3. Seam 生命周期加强让我们来思索其中一些加强，由于它们适用于 JSF 开发中一些常见的挑战。并不复杂的配置Seam 演示了 Java 5 注释的一个非常适用的用法。Seam 的部署扫描程序检查一切包含 perties 文件的归档文件，并为一切标有 Name 注释的类创建一个 Seam 组件。由于 Java 言语缺乏用于在代码级添加元数据的一种公共语法，因此需求设计很多 XML 配置。当 Java 5 规范中参与注释后，就获得了一个更好的处理方案。由于大多数 backing bean 是为了在特定运

22、用程序中运用而开发的，因此没有理由将这些 bean 的配置 “笼统 到类本身以外的任何文件中。附带的益处是，您可以少处置一个文件。Seam 提供了一组完好的注释来协助 将 bean 集成到 JSF 生命周期中。清单 4 显示了其中一些。页面动作和 RESTful URL在不运用组件框架的情况下，另一个必需处理的熟习的问题是预先处置每个恳求，就像在基于动作的框架中那样。受此影响的用例是 RESTful URL、书签支持、经过 URL 方式获得的平安性以及页面流验证等。这也是学习运用 JSF 的开发人员容易感到困惑的主要缘由之一。有些 JSF 供应商经过用开发人员工具提供 onPageLoad 功

23、能来绕过这个问题见 参考资料，但这不是中心规范的一部分。当用户直接从书签比如恳求一个商品详细信息屏幕时，通常会发生什么事情呢？由于 JSF 控制器采取被动方式，当页面开场呈现时，即使明显没有目的数据，也不能将用户重新带到逻辑流的开场处。相反，这种情况下只能显示一个空页面，其中只需一些空值或其他能够存在的假信号。首先，您能够会天性地想要在页面的主 backing bean 上实现一个 “divrender 方法。然而，在组件框架中，backing bean 与页面之间的关系并不一定都是一对一的。每个页面能够依赖于多个 backing bean，每个那样的 bean 也能够在多个不同的页面上运用。

24、必需用某种方式将一个视图 ID例如 /user/detail.jspx与一个或多个方法关联起来，中选择呈现相应的视图模板时就调用这个些方法。您可以运用 phase-listener 方法，但是这依然需求定制的逻辑来确定对于当前视图和阶段能否应该执行该功能。这种处理方案不但会导致很多冗余逻辑，而且会将视图 ID很能够是运用程序中最不确定的部分硬编码到编译后的 Java 代码中。页面动作来协助 Seam 的页面动作可以协助 您预先拦截呈现的假信号。页面动作是运用方法绑定指定的，方法绑定在进入页面时、Render Response 阶段之前执行。对于 /WEB-INF/pages.xml 配置文件中

25、一个给定的视图 ID，可以配置恣意数量的方法绑定。或者，可以经过将它们放在视图模板临近的一个文件中，复制它的称号，但是将文件扩展名换为 *.page.xml，从而分解每个页面的定义。对于页面动作，XML 是有必要的，由于视图 ID 非常容易变化。就像 JSF 经过 Apply Request Values 阶段的值绑定将 post 数据映射到模型对象一样， Seam 可以经过执行页面动作之前的值绑定将恣意恳求参数映射到模型对象。这些恳求参数注入的配置嵌套在页面动作 XML 声明中。假设页面动作方法调用前往一个非空字符串值，那么 Seam 将其当作一个导航事件。因此，不用迁移到一个完好的基于动作

26、的框架中，依然可以比得上最特别的特性。Seam 包括很多内置的页面动作，它们通常跨运用程序运用。其中包括用于验证 conversation 能否建立的一个动作；可以启动、嵌套和终了 conversation 的动作；处置预期异常的动作；以及确保适当的凭证的动作。页面动作是启用对 JSF 的书签支持的关键。Seam 的创建者允许在进入页面时恳求参数 actionMethod 触发一个方法调用，从而利用了这一特性。更妙的是，您不需求做任何额外的任务就能为书签创建链接。 Seam 提供了两个组件标志：s:link 和 s:button，用以处置细节。这两个标志分别对应于 JSF 中的 h:comma

27、ndLink 和 h:commandButton。不同之处在于，Seam 组件标志组装的链接运用一个 GET 操作发出恳求，而不是运用 JSF 的 POST 表单提交模型表示。因此，Seam 创建的链接对书签更 “友好，对于开发人员来说更方便。您能够还留意到，当运用页面动作时，地址栏中的 URL 对应于正在显示的页面，而不总是背后的一个页面。后一种情况之所以会发生，是由于 JSF 将表单配置为 post 回生成它们的 URL。地址栏没有更新，以反映执行动作后的新视图，由于 JSF 经过一个效力器端重定向使之前进。假设您想演示页面动作的灵敏性，那么可以运用它们来创建 RESTful URL例如

28、/faces/product/show/10。为此，将页面动作方法映射到视图 ID“/product/show/*，其中 /faces 前缀是 JSF servlet 映射部分。然后，该页面动作方法利用恳求 URL，以判别数据类型和数据标识符，加载数据，然后导航到适当的模板。这个例子很明显地演示了 JSF 恳求 URL 与视图模板之间并不一定存在一对一的关系。工厂组件JSF 最大的一个失败是没有在用户触发的动作或动作监听器方法以外的其他地方提供可靠的时机来为视图预备数据。将逻辑放在一个动作方法中并不能保证该逻辑在视图呈现之前得到执行，由于页面视图并不总是在用户触发的事件之后。例如，当一个 JS

29、F 运用程序的 URL 第一次被恳求时，会发生什么情况？假设需求在该页面上显示从效力层获得的一组数据，那么在 JSF 生命周期中一直没有好的时机来取数据。您能够会以为，可以将逻辑放在映射到视图中值绑定表达式的 backing bean 的 getter 方法中。但是，每当 JSF 解析那个表达式时，就会触发另一个调用，新的调用又会访问效力层。即使页面上只需少数几个组件，getter 方法也能够被推后数次执行。显然，就性能而言这不是最优的。即使经过运用受管 bean 上的私有属性维护形状，每当面对那样的情况时，依然必需添加额外的管道。一种处理方案是运用 Seam 的页面动作。但是由于这种义务是如

30、此常见，Seam 提供了一个更加容易的处理方案。Seam 引入了工厂数据提供者factory data provider的概念，工厂数据提供者由 Factory Java 5 注释指定。虽然有两种方法配置工厂，但是最终结果是同样的数据只需在第一次被恳求时预备一次。 Seam 确保随后对一样数据的恳求将直接前往之前创建的结果集，而不用再一次触发对查找方法的调用。经过与 conversation 相结合，工厂数据提供者成为实现数据短期缓存的非常强大的特性，否那么，取这些数据的代价能够较高。在 JSF 不担任减少它解析一个值绑定表达式的次数的情况下，Seam 的工厂特性经常变得非常方便。有形状 co

31、nversation关于 JSF 很容易引起困惑的一个地方是它的形状管理功能。JSF 规范解释了在接纳一个动作之后页面是如何 “恢复restored 的，在此期间时间事件要进展排队，选择要注册。仔细研讨规范中的用词可以发现，虽然在 postback 上恢复了组件树，但是那些组件运用的 backing bean 数据并没有被恢复。组件只是以字符串文字的方式存储值绑定运用 #value 语法的 EL 表达式，只在运转时解析底层数据。这意味着假设一个值是短期作用域存储的，例如页面或恳求作用域，那么当 JSF 生命周期到达 Restore View 阶段时，这个值将消逝。不将值绑定数据存储在组件树中的

32、一个最值得留意的不利方面是虚幻事件效果见 参考资料，这是由 UIData 家族中的暂时父组件导致的。假设一个值绑定表达式援用的模型数据不再可用，或者在组件树被恢复之前发生了更改，那么组件树的一些部分将被撤销。假设在这些被撤销的分支中，有一个组件中触发了一个事件，那么它将不能被发现，而且这种事件丧失情况是难于觉察的。只是队列开发人员能够会惊呼 “为什么我的动作没有被调用？虽然丧失的事件看上去像是异常情况，但并不会导致 JSF 生命周期中出现红色标志。由于这些组件依赖底层数据，以坚持稳定和适当地被恢复，所以 JSF 难于知道丧失了什么。不幸的是，JSF 规范天真地引导开发人员将大多数 backin

33、g bean 放入 conversation 作用域中 ? 甚至可以在 “方便的 作用域内调用它。然后，效力器管理员那么必需处置由此导致的 “内存溢出 错误，集群环境中的效力器类似性，以及效力器重启时的串行化异常。MyFaces Tomahawk 工程经过 t:saveState 标志的方式提供了对虚幻事件的一个处理方案。MyFaces 标志允许将数据包括整个 backing bean存储为组件树的一部分，而仅仅是值绑定。然而，这种处理方案有些简陋，很像运用隐藏的表单字段在恳求之间传送值。它还呵斥视图与控制器之间严密耦合。Seam 的创建者认识到，Java Servlet 规范中三个内置的上下

34、文恳求、会话和运用程序缺乏以构成数据驱动的 Web 运用程序的全部作用域。在 Seam 中，他们引入了 conversation 作用域，这是一个有形状作用域，由页面流的起止点界定。Seam 的 conversation 作用域“Seam 强调运用有形状组件。 Seam 参考文档中的这句话表达了 Seam 的中心思想。很长一段时间内，关于 Web 运用程序的看法是，它们是无形状的 ? 这种思想一定程度上要归因于 协议的无形状性质。大多数框架为了迎合这一点，在终了页面呈现之前提供 one-shot-processing。这种方法导致很大的阻力，由于任何大的运用程序都需求长时间运转的 conver

35、sation 来满足某些用例。需求有形状上下文的运用程序的例子有很多，例如存储检查过程、产品定制、多页表单导游和很多其他基于线形交互的运用程序。虽然其中有些例子可以经过运用 URL 参数aka RESTful URL和隐藏字段在页面之间迁移数据，但是这样做对于开发人员来说有些繁杂。而且，如今这种做法曾经过时了。由于大多数 Web 框架依然在无形状模型下操作，所以您经常发现本人走出了这种框架，而 “开辟 出定制处理方案。JSF 大量依赖于 会话，试图引入有形状上下文。实践上，当和会话作用域的 backing bean 一同运用时，JSF 组件的行为要好得多。假设不小心设计，过度运用 会话会导致严

36、重的内存走漏、性能瓶颈和平安问题。此外，在多标签阅读器环境中，运用 会话能够导致非常奇异的行为，破坏用户神圣的 Back 按钮。值得留意的是，JSF 只是与您互作退让：它是一个有形状 UI，处置保管和恢复组件树的一切细节，但是它在保管和恢复数据方面没有提供协助 。因此，JSF 带来有形状 UI，而您那么带来有形状数据。不幸的是，需求由您来担任确保它们是相符的。在 Seam 之前，运用有形状数据的独一方便的方式是依赖于 会话。Seam 纠正了这个问题，它经过建立一个全新的 conversation 作用域，完善了 JSF 的形状管理。随着将 Seam 添加到 JSF 生命周期中，conversa

37、tion 上下文与一个阅读器窗口或标签页联络在一同，这个阅读器窗口或标签页由随每个恳求提交的一个标志来标识。conversation 作用域运用 会话的一个单独的区段在页面之间迁移数据。记住，Seam 运用 会话用于 conversation 耐久性这一点是完全透明的。 Seam 并不是不担任任地将组件推卸到 会话中，使其茫然地呆在那里。相反，Seam 小心地管理那个区段的会话数据的生命周期，并且当 conversation 终止时，自动去除它们。Seam 聪明地运用双射来允许以一种新的阐明性方式使数据流入和流出一个 “Web conversation 的每个页面。 Seam 的 conver

38、sation 作用域同时还抑制了 会话的限制，协助 开发人员放弃运用 会话。异常处置Seam 的创建者曾说过：“在异常处置方面，JSF 非常有限。这一点显然毫无争议。 JSF 规范完全忽视异常管理，将责任完全放在 servlet 容器上。允许 servlet 容器处置异常的问题在于，这严重限制了错误页面上显示的内容，并且制止了事务回滚。由于错误页面是在恳求分发器转发之后显示的，FacesContext 不再在作用域中，因此这时执行业务逻辑就太迟了。您的最后一线希望是运用 Servlet API，并抓住 javax.servlet.error.* 恳求属性，以搜索能阐明出错处的信息。这一点上，Seam 再次扮演救世主，它提供了优雅的、阐明性方式的异常处置。异常管理可以经过注释指定，或者在配置文件中指定。可以将注释 HttpError、Redirect 和 ApplicationException 放在异常类的上面，阐明当异常被抛出时应该采取的动作。对于那些不能修正的异常类，可以运用 XML 配置选项。Seam 中的异常管理器担任发送 形状码、执行重定向、促使页面呈现、终止 conversation 和定制出现异常时的用户音讯。由于在开场呈现呼