blocks|key|3465480|text|这是因为按照JSF规范，ViewExpiredException被包装在ServletException中。以下是JSF+1.2+specification第10.2.6.2章的摘录|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3465481|3465482|+10.2.6.2+FacesServlet|blockquote|3465483|3465484|调用保存的Lifecycle实例的execute()方法，将此请求的FacesContext实例作为参数传递。如果execute()方法抛出FacesException，则以+ServletException+作为根本原因重新抛出它。|BOLD|3465485|3465486|Servlet+API规范中指定了如何分配错误页。以下是Servlet+API+specification+2.5第9.9.2章的摘录|3465487|3465488|+SRV.9.9.2错误页|3465489|3465490|如果没有包含exception-type的+error-page声明符合类层次结构匹配，并且抛出的异常是ServletException或其子类，则容器提取包装的异常，如ServletException.getRootCause方法所定义的那样。对错误页声明进行第二遍，再次尝试与错误页声明进行匹配，但使用包装的异常。|3465491|3465492|在类层次结构中，ServletException已经与Throwable匹配，因此不会在第二次遍历时提取其根本原因。|3465493|要证明此指定行为，请将javax.faces.application.ViewExpiredException替换为javax.servlet.ServletException作为<exception-type>，然后重试。您将看到预期的错误页面正在显示。|3465494|要解决这个问题，只需在java.lang.Throwable或java.lang.Exception上删除错误页面即可。如果没有一个异常特定的错误页面匹配，那么无论如何它都会返回到500的错误代码。所以，你需要做的就是：|3465495|<error-page>+
++++<exception-type>javax.faces.application.ViewExpiredException</exception-type>+
++++<location>/jsps/utility/sessionExpired.jsp</location>+
</error-page>+
<error-page>
++++<error-code>500</error-code>
++++<location>/jsps/utility/technicalError.jsp</location>
</error-page>|code-block|syntax|javascript|3465496|3465497|bean更新：根据OP的(已删除)注释:为了可靠地测试这一点，您不能在构造函数或方法中执行throw+new+ViewExpiredException()。反过来，它会被某个EL异常所包裹。最后，您可以在Filter中添加一个打印rootCause的调试行，以亲自查看它。|3465498|如果您使用的是Eclipse/Tomcat，测试ViewExpiredException的快速方法如下所示：|3465499|Tomcat使用一个简单的命令按钮创建一个页面，部署并运行它，然后在webbrowser.|3465500|Go中打开它返回到|ordered-list-item|3465501|，右键单击Tomcat并选择Clean+Tomcat+Work+Directory。这将重新启动Tomcat+和回收站所有序列化会话(重要！仅仅重新启动Tomcat是不够的)。返回到and浏览器并按下命令按钮(无需重新加载页面beforehand!).|3465502|+)|3465503|unordered-list-item|3465504|3465505|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.oracle.com/javaee/6/api/javax/faces/application/ViewExpiredException.html|1|http://docs.oracle.com/javaee/6/api/javax/servlet/ServletException.html|2|http://jcp.org/aboutJava/communityprocess/mrel/jsr252/index2.html|3|http://jcp.org/aboutJava/communityprocess/mrel/jsr154/index2.html^0|C|K|10|G|C|K|0|10|G|1|1L|L|2|0|0|0|0|5|9|H|9|Y|C|1L|9|1Y|E|2G|G|2G|G|2X|6|0|0|S|T|3|0|0|0|0|6|E|M|A|1G|G|2D|T|10|7|3F|B|0|0|8|G|R|9|0|B|18|1M|U|2I|G|0|B|J|V|J|2I|3|0|0|0|Z|2T|19|W|2U|6|37|9|0|0|1I|O|K|0|0|19|0|0|9|0|0|3I|0|0|2|0|0|0^^$0|@$1|2|3|4|5|6|7|23|8|@$9|24|A|25|B|C]|$9|26|A|27|B|C]]|D|@$9|28|A|29|1|2A]|$9|2B|A|2C|1|2D]|$9|2E|A|2F|1|2G]]|E|$]]|$1|F|3|-4|5|6|7|2H|8|@]|D|@]|E|$]]|$1|G|3|H|5|I|7|2I|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|2J|8|@]|D|@]|E|$]]|$1|K|3|L|5|6|7|2K|8|@$9|2L|A|2M|B|C]|$9|2N|A|2O|B|C]|$9|2P|A|2Q|B|C]|$9|2R|A|2S|B|C]|$9|2T|A|2U|B|C]|$9|2V|A|2W|B|C]|$9|2X|A|2Y|B|M]|$9|2Z|A|30|B|M]]|D|@]|E|$]]|$1|N|3|-4|5|6|7|31|8|@]|D|@]|E|$]]|$1|O|3|P|5|6|7|32|8|@]|D|@$9|33|A|34|1|35]]|E|$]]|$1|Q|3|-4|5|6|7|36|8|@]|D|@]|E|$]]|$1|R|3|S|5|I|7|37|8|@]|D|@]|E|$]]|$1|T|3|-4|5|6|7|38|8|@]|D|@]|E|$]]|$1|U|3|V|5|6|7|39|8|@$9|3A|A|3B|B|C]|$9|3C|A|3D|B|C]|$9|3E|A|3F|B|C]|$9|3G|A|3H|B|C]|$9|3I|A|3J|B|M]|$9|3K|A|3L|B|M]]|D|@]|E|$]]|$1|W|3|-4|5|6|7|3M|8|@]|D|@]|E|$]]|$1|X|3|Y|5|6|7|3N|8|@$9|3O|A|3P|B|C]|$9|3Q|A|3R|B|C]]|D|@]|E|$]]|$1|Z|3|10|5|6|7|3S|8|@$9|3T|A|3U|B|C]|$9|3V|A|3W|B|C]|$9|3X|A|3Y|B|C]]|D|@]|E|$]]|$1|11|3|12|5|6|7|3Z|8|@$9|40|A|41|B|C]|$9|42|A|43|B|C]|$9|44|A|45|B|C]]|D|@]|E|$]]|$1|13|3|14|5|15|7|46|8|@]|D|@]|E|$16|17]]|$1|18|3|-4|5|6|7|47|8|@]|D|@]|E|$]]|$1|19|3|1A|5|6|7|48|8|@$9|49|A|4A|B|M]|$9|4B|A|4C|B|C]|$9|4D|A|4E|B|C]|$9|4F|A|4G|B|C]]|D|@]|E|$]]|$1|1B|3|1C|5|6|7|4H|8|@$9|4I|A|4J|B|M]|$9|4K|A|4L|B|C]]|D|@]|E|$]]|$1|1D|3|1E|5|6|7|4M|8|@$9|4N|A|4O|B|M]]|D|@]|E|$]]|$1|1F|3|1G|5|1H|7|4P|8|@$9|4Q|A|4R|B|M]]|D|@]|E|$]]|$1|1I|3|1J|5|1H|7|4S|8|@$9|4T|A|4U|B|M]]|D|@]|E|$]]|$1|1K|3|1L|5|6|7|4V|8|@$9|4W|A|4X|B|M]]|D|@]|E|$]]|$1|1M|3|-4|5|1N|7|4Y|8|@]|D|@]|E|$]]|$1|1O|3|-4|5|6|7|4Z|8|@]|D|@]|E|$]]|$1|1P|3|-4|5|6|7|50|8|@]|D|@]|E|$]]]|1Q|$1R|$5|1S|1T|1U|E|$1V|1W]]|1X|$5|1S|1T|1U|E|$1V|1Y]]|1Z|$5|1S|1T|1U|E|$1V|20]]|21|$5|1S|1T|1U|E|$1V|22]]]]

This is because the <a href="http://docs.oracle.com/javaee/6/api/javax/faces/application/ViewExpiredException.html" rel="nofollow noreferrer"><code>ViewExpiredException</code></a> is been wrapped in a <a href="http://docs.oracle.com/javaee/6/api/javax/servlet/ServletException.html" rel="nofollow noreferrer"><code>ServletException</code></a> as per the JSF specification. Here's an extract of chapter 10.2.6.2 of the <a href="http://jcp.org/aboutJava/communityprocess/mrel/jsr252/index2.html" rel="nofollow noreferrer">JSF 1.2 specification</a>:

<blockquote>
 <h3>10.2.6.2 FacesServlet</h3>
 
 Call the <code>execute()</code> method of the saved <code>Lifecycle</code> instance, passing the
 <code>FacesContext</code> instance for this request as a parameter. If the <code>execute()</code> method
 throws a <code>FacesException</code>, re-throw it as a <code>ServletException</code> with the
 <code>FacesException</code> as the root cause.
</blockquote>

How the error pages are allocated is specified in Servlet API specification. Here's an extract of chapter 9.9.2 of <a href="http://jcp.org/aboutJava/communityprocess/mrel/jsr154/index2.html" rel="nofollow noreferrer">Servlet API specification 2.5</a>:

<blockquote>
 <h3>SRV.9.9.2 Error Pages</h3>
 
 If no <code>error-page</code> declaration containing an <code>exception-type</code> fits using the
 class-hierarchy match, and the exception thrown is a <code>ServletException</code> or
 subclass thereof, the container extracts the wrapped exception, as defined by
 the <code>ServletException.getRootCause</code> method. A second pass is made over the error
 page declarations, again attempting the match against the error page
 declarations, but using the wrapped exception instead.
</blockquote>

In class hierarchy, <code>ServletException</code> already matches <code>Throwable</code>, so its root cause won't be extracted for the second pass.

To prove this specified behaviour, replace <code>javax.faces.application.ViewExpiredException</code> by <code>javax.servlet.ServletException</code> as <code>&lt;exception-type&gt;</code> and retry. You'll see the expected error page being displayed.

To solve this, simply remove the error page on <code>java.lang.Throwable</code> or <code>java.lang.Exception</code>. If no one exception specific error page matches, then it will fall back to the one for error code of <code>500</code> anyway. So, all you need is this:

<pre><code>&lt;error-page&gt; 
 &lt;exception-type&gt;javax.faces.application.ViewExpiredException&lt;/exception-type&gt; 
 &lt;location&gt;/jsps/utility/sessionExpired.jsp&lt;/location&gt; 
&lt;/error-page&gt; 
&lt;error-page&gt;
 &lt;error-code&gt;500&lt;/error-code&gt;
 &lt;location&gt;/jsps/utility/technicalError.jsp&lt;/location&gt;
&lt;/error-page&gt;
</code></pre>

<hr>

Update: as per the (deleted) comment of the OP: to reliably test this you cannot do a <code>throw new ViewExpiredException()</code> in a bean constructor or method or so. It would in turn get wrapped in some EL exception. You can eventually add a debug line printing <code>rootCause</code> in the <code>Filter</code> to see it yourself. 

If you're using Eclipse/Tomcat, a quick way to test <code>ViewExpiredException</code> is the following: 

<ol>
<li>Create a JSF page with a simple command button, deploy and run it and open it in webbrowser.</li>
<li>Go back to Eclipse, rightclick Tomcat server and choose Clean Tomcat Work Directory. This will restart Tomcat and trash all serialized sessions (important! just restarting Tomcat is not enough). </li>
<li>Go back to webbrowser and press the command button (without reloading page beforehand!).</li>
</ol>

blocks|key|3252361|text|正如BylusC所提到的，部署描述符不能包含任何将捕获ViewExpiredException+(包装在ServletException中)的错误页面处理程序，而不能包含正确的ViewExpiredException错误页面。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3252362|不要忘记验证服务器的部署描述符(例如TomEE/conf/web.xml)不包含java.lang.Throwable或java.lang.Exception错误页定义。因为这两个web.xml基本上是合并的。|3252363|是-应用程序的web.xml优先于服务器的web.xml，但如果应用程序的web.xml包含|3252364|500+(/error.xhtml)的|3252365|错误-页面|unordered-list-item|3252366|3252367|和服务器的web.xml|3252368|3252369|500+(/500.html)和|3252370|可线程(/bigerror.html)|3252371|3252372|则应用程序上下文将包含这两者的合并：|3252373|3252374|500+(/error.xhtml)|3252375|Throwable+(/bigerror.html)|3252376|3252377|并且ViewExpiredExcpetion错误处理将不能正常工作。|3252378|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|16|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|17|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|18|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|19|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1B|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|1D|8|@]|9|@]|A|$]]|$1|Q|3|R|5|J|7|1E|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1G|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|W|3|X|5|J|7|1I|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|J|7|1J|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|1L|8|@]|9|@]|A|$]]|$1|13|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]]|14|$]]

As mentioned by BylusC, deployment descriptor must not contain any error-page handler that will catch ViewExpiredException (wrapped inside ServletException) instead of the correct one - error-page for ViewExpiredException.
Do not forget to verify that server's deployment descriptor (e.g. TomEE/conf/web.xml) does not contain java.lang.Throwable or java.lang.Exception error-page definitions. Because these two web.xml are basically merged.
Yes - application's web.xml has precedence over server's web.xml, but if application's web.xml contains
<ul>
<li>error-page for 500 (/error.xhtml)</li>
</ul>
and server's web.xml for
<ul>
<li>500 (/500.html) and for</li>
<li>Throwable (/bigerror.html)</li>
</ul>
then application context will contain merge of those two:
<ul>
<li>500 (/error.xhtml)</li>
<li>Throwable (/bigerror.html)</li>
</ul>
and ViewExpiredExcpetion error handling will not work correctly.

I'm working on a JSF web application in which I need to bring up a "Session Expired" page if the view expires, but a general technical error page for all others. The application only goes to the technical error page when I trigger the exception. Here's the error-page definitions:

<pre><code>&lt;error-page&gt; 
 &lt;exception-type&gt;javax.faces.application.ViewExpiredException&lt;/exception-type&gt; 
 &lt;location&gt;/jsps/utility/sessionExpired.jsp&lt;/location&gt; 
&lt;/error-page&gt; 
&lt;error-page&gt; 
 &lt;exception-type&gt;java.lang.Throwable&lt;/exception-type&gt; 
 &lt;location&gt;/jsps/utility/technicalError.jsp&lt;/location&gt; 
&lt;/error-page&gt; 
&lt;error-page&gt;
 &lt;error-code&gt;500&lt;/error-code&gt;
 &lt;location&gt;/jsps/utility/technicalError.jsp&lt;/location&gt;
&lt;/error-page&gt;
</code></pre>

I removed the technicalError.jsp error page elements and it worked fine, but when I put them back I can't get to the sessionExpired.jsp page. How do I tell the web container the order to evaluate these tags so that the right page comes up? Thanks.

ViewExpiredException shown in java.lang.Throwable error-page in web.xml

服务器

Eclipse

容器

我正在开发一个JSF web应用程序，如果视图过期，我需要调出一个“会话过期”页面，但对于所有其他页面，需要调出一个一般的技术错误页面。当我触发异常时，应用程序只会转到技术错误页面。下面是错误页的定义：<error-page> <exception-type>javax.faces.application.Vi...

问java.lang.Throwable错误中显示的ViewExpiredException - web.xml中的页面
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问java.lang.Throwable错误中显示的ViewExpiredException - web.xml中的页面EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问java.lang.Throwable错误中显示的ViewExpiredException - web.xml中的页面
EN