JSF 大量依赖于 HTTP 会话，试图引入有状态上下文。实际上，当和会话作用域的 backing bean 一起使用时，JSF 组件的行为要好得多。如果不小心设计，过度使用 HTTP 会话会导致严重的内存泄漏、性能瓶颈和安全问题。此外，在多标签浏览器环境中，使用 HTTP 会话可能导致非常奇怪的行为，破坏用户神圣的 Back 按钮。值得注意的是，JSF 只是与您互作让步：它是一个有状态 UI，处理保存和恢复组件树的所有细节，但是它在保存和恢复数据方面没有提供帮助。因此，JSF 带来有状态 UI，而您则带来有状态数据。不幸的是，需要由您来负责确保它们是相符的。

在 Seam 之前，使用有状态数据的惟一方便的方式是依赖于 HTTP 会话。Seam 纠正了这个问题，它通过建立一个全新的 conversation 作用域，完善了 JSF 的状态管理。随着将 Seam 添加到 JSF 生命周期中，conversation 上下文与一个浏览器窗口（或标签页）联系在一起，这个浏览器窗口（或标签页）由随每个请求提交的一个标志来标识。conversation 作用域使用 HTTP 会话的一个单独的区段在页面之间迁移数据。记住，Seam 使用 HTTP 会话用于 conversation 持久性这一点是完全透明的。 Seam 并不是不负责任地将组件推卸到 HTTP 会话中，使其茫然地呆在那里。相反，Seam 小心地管理那个区段的会话数据的生命周期，并且当 conversation 终止时，自动清除它们。Seam 聪明地使用双射来允许以一种新的说明性方式使数据流入和流出一个 “Web conversation” 的每个页面。 Seam 的 conversation 作用域同时还克服了 HTTP 会话的限制，帮助开发人员放弃使用 HTTP 会话。

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

异常处理

Seam 的创立者曾说过：“在异常处理方面，JSF 非常有限”。这一点显然毫无争议。 JSF 规范完全忽视异常管理，将责任完全放在 servlet 容器上。允许 servlet 容器处理异常的问题在于，这严重限制了错误页面上显示的内容，并且禁止了事务回滚。由于错误页面是在请求分发器转发之后显示的，FacesContext 不再在作用域中，因此这时执行业务逻辑就太迟了。您的最后一线希望是使用 Servlet API，并抓住 javax.servlet.error.* 请求属性，以搜索能表明出错处的信息。

这一点上，Seam 再次扮演救世主，它提供了优雅的、说明性方式的异常处理。异常管理可以通过注释指定，或者在配置文件中指定。可以将注释 @HttpError、@Redirect 和 @ApplicationException 放在异常类的上面，表明当异常被抛出时应该采取的动作。对于那些不能修改的异常类，可以使用 XML 配置选项。Seam 中的异常管理器负责发送 HTTP 状态码、执行重定向、促使页面呈现、终止 conversation 和定制出现异常时的用户消息。由于在开始呈现响应之后，JSF 不能改变动作的过程，一些固有的限制规定了何时才能处理这些异常。通过适当使用其他 Seam 特性，例如页面动作，可以确保大多数异常情况在呈现响应之前得到解决。

Ajax remoting

由于最后发行的 JSF 规范几乎与 Ajax 重合，JSF 框架在异步 JavaScript 和局部页面呈现（partial page rendering）方面帮助不大。在某些时候，甚至这两种类型的编程甚至不一致。最终的解决办法是建议使用 JSF PhaseListener 或组件 Renderer 来处理局部页面更新。即使如此，这一点仍然很明显：JSF 使得 Ajax 比过去更难于采用。有些项目，例如 ICEfaces，甚至用一个更好的、专为页面－服

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!