服务器如何确定使用哪种类型的web.xml错误页面的优先级? [英] How does server prioritize which type of web.xml error page to use?

查看:179
本文介绍了服务器如何确定使用哪种类型的web.xml错误页面的优先级?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有两个错误页面; 1代表SpecificExceptionA,另一个代表Throwable.

I have two error pages; 1 is for SpecificExceptionA and the other is for Throwable.

<error-page>
  <exception-type>org.SpecificExceptionA</exception-type>
  <location>/WEB-INF/views/error/timedout.jsp</location>
</error-page>

<error-page>
  <exception-type>java.lang.Throwable</exception-type>
  <location>/WEB-INF/views/error/error.jsp</location>
</error-page>

如果我在web.xml中定义了这两个属性,则所有内容都将移至/error/error.jsp.

If I have both of these defined in my web.xml everything goes to /error/error.jsp.

如果仅定义了特定的异常,它将转到正确的页面;但其他错误归于tomcat的默认设置(404除外)

If I have just the specific exception defined, it goes to the proper page; but other errors go to the tomcat default (except 404)

是否有更好的方法来指定特定的异常处理程序?我正在使用Spring 3.0.

Is there a better way to specify specific exception handlers? I'm using spring 3.0.

推荐答案

这不是特定于Tomcat的.这特定于Servlet API. Servlet API规范2.5 .这是相关的摘录:

This is not specific to Tomcat. This is specific to the Servlet API. How the error page is determined is specified in chapter 9.9.2 of Servlet API specification 2.5. Here's an extract of relevance:

SRV.9.9.2错误页面

如果没有包含exception-typeerror-page声明不适合使用 类层次结构匹配,并且抛出的异常是ServletException或 子类,容器提取包装的异常,如 ServletException.getRootCause方法.对错误进行第二次通过 页面声明,再次尝试与错误页面匹配 声明,但改用包装的异常.

SRV.9.9.2 Error Pages

If no error-page declaration containing an exception-type fits using the class-hierarchy match, and the exception thrown is a ServletException or subclass thereof, the container extracts the wrapped exception, as defined by the ServletException.getRootCause 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.

因此,您的SpecificExceptionA很可能包裹在 ServletException ,因此java.lang.Throwable是第一​​遍最接近的匹配.当您删除该条目时,将通过包装的异常进行第二次传递,因此您的SpecificExceptionA将获得匹配.

So, your SpecificExceptionA was likely wrapped in a ServletException and thus the java.lang.Throwable is the closest match on 1st pass. When you remove this entry, a 2nd pass will be made with the wrapped exception and thus your SpecificExceptionA get a match.

定义常规HTTP 500错误页面的正确方法是将其映射到error-code而不是exception-type:

The right way to define a general HTTP 500 error page is to map it on error-code instead of exception-type:

<error-page>
    <exception-type>org.SpecificExceptionA</exception-type>
    <location>/WEB-INF/views/error/timedout.jsp</location>
</error-page>
<error-page>
    <error-code>500</error-code>
    <location>/WEB-INF/views/error/error.jsp</location>
</error-page>

如果由于某些不清楚的原因而无法选择此选项,则解决此问题的方法之一是创建一个Filter,该Filter侦听/*url-pattern并基本上执行以下操作:

If this is not an option for some unclear reason, one of the ways to workaround this is to create a Filter which listens on an url-pattern of /* and does basically the following:

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws ServletException, IOException {
    try {
        chain.doFilter(request, response);
    } catch (ServletException e) {
        Throwable rootCause = e.getRootCause();
        if (rootCause instanceof SpecificExceptionA) {
            throw (SpecificExceptionA) rootCause;
        } else {
            throw e;
        }
    }
}

它只需要从RuntimeException扩展即可使用.

It only has to extend from RuntimeException to get it to work.

这篇关于服务器如何确定使用哪种类型的web.xml错误页面的优先级?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆