自上次写博客以来已经有一段时间了。 我一直在考虑写一些技术博客,但最终却忙于其他事情。 上周,在Coderanch论坛上进行了非常有趣的讨论。 甚至更有趣,因为它涉及JBoss。
熟悉Java EE Web应用程序的开发人员会知道,Web应用程序部署描述符(web.xml)允许您指定当服务器抛出特定异常(类)或错误代码时容器将显示的“错误页面”,网络请求。 这是一个简短的示例:
<web-app> ... <!-- A custom error page for error code == 500 --> <error-page> <error-code>500</error-code> <location>/my-foo-bar-500-page.html</location> </error-page> <!-- A custom error page for exception type org.myapp.foo.bar.MyException --> <error-page> <exception-type>org.myapp.foo.bar.MyException</exception-type> <location>/my-foo-bar-exception-page.html</location> </error-page> ... </web-app>
足够简单–分别为特定的错误代码和异常类型定义的几个自定义错误页面。 所有这些都很好。 当前,在开发Web应用程序时,越来越多的编程模型和框架出现在人们的视野中。 CDI和JSF就是其中一些。 CDI具有范围的概念(例如:请求范围,会话范围,应用程序范围,对话范围)。 我们不会详细介绍它们的含义和使用时间,但让我们考虑一下此博客中的对话范围,因为这正是促使该博客的论坛主题中有关讨论的内容。
因此,CDI允许多个请求成为“对话范围”的一部分。 对话具有“开始”和“结束”,两者都可以由应用程序管理。 当应用程序涉及JSF时,所有对话(id)都会自动传播到JSF请求。 除了明确的对话开始/结束界限外,对话也可能超时。 涉及对话已结束或超时的请求将遇到异常。
因此,我们知道CDI对话范围有一些背景。 因此,让我们考虑一种情况,当引发“不再存在的对话”异常(可能是由于超时)时,应用程序希望呈现美观的页面。 我们已经看到了如何为错误页面配置编写一个web.xml,它很简单:
<web-app> ... <!-- A custom error page for exception type org.jboss.weld.context.NonexistentConversationException --> <error-page> <exception-type>org.jboss.weld.context.NonexistentConversationException</exception-type> <location>/my-foo-bar-exception-page.html</location> </error-page> ... </web-app>
很简单。 org.jboss.weld.context.NonexistentConversationException是异常类类型,当会话超时时会抛出该异常类(请注意,我们假设Web应用程序依赖于Weld作为CDI规范实现库)。 上面的配置工作正常。 抛出org.jboss.weld.context.NonexistentConversationException时,将显示my-foo-bar-exception-page.html。 但是,现在让我们考虑,就像我们应用程序的其他部分一样,我们希望在错误页面中包含JSF。 因此,让我们将错误页面指向映射到JSF servlet的URL模式:
<web-app> ... <!-- A custom error page for exception type org.jboss.weld.context.NonexistentConversationException. Notice the "nocid" parameter being passed to make sure that the non-existent conversation id isn't passed to the error page --> <error-page> <exception-type>org.jboss.weld.context.NonexistentConversationException</exception-type> <location>/my-foo-bar-exception-page.xhtml?nocid=true</location> </error-page> ... </web-app>
请注意,我们将“ nocid”参数作为错误页面位置的查询字符串的一部分传递。 “ nocid”参数的值实际上并不重要,但是为了保持该值的逻辑性,我们在这里使用了“ true”值。 完成此更改后,您将开始注意到错误页面(由JSF支持)现在可以正确呈现!
我们花了一段时间才在该论坛线程中找到此解决方案,因为它看起来很简单,应该可以“正常工作”,但事实并非如此。这是我一直在谈论的Coderanch论坛线程 。 感谢Greg Charles找出如何传递该nocid参数。
参考: Jaikiran My Wiki博客上来自JCG合作伙伴 Jaikiran Pai的涉及CDI和JSF的过期对话的自定义错误页面 。
翻译自: https://www.javacodegeeks.com/2013/01/custom-error-pages-for-expired-conversations-involving-cdi-and-jsf.html