Details
-
Bug
-
Status: Closed
-
Normal
-
Resolution: Fixed
-
2.26.12, 2.28.05
-
None
-
None
Description
HstFilter has the following:
try
{ // ... chain.doFilter(request, response); // ... }catch (ContainerException e)
{ logger.warn(e.getClass().getName() + " for '" + req.getRequestURI() + "':", e); sendError(req, res, HttpServletResponse.SC_INTERNAL_SERVER_ERROR); }catch (Exception e)
{ logger.warn("Unknown error encountered while processing request '" + req.getRequestURI() + "':", e); sendError(req, res, HttpServletResponse.SC_INTERNAL_SERVER_ERROR); }finally
{ // ... }Because HstFilter is mapped to '/*', every URL request (e.g, /examples/test.jsp) is passed through HstFilter.
The problem is that if you get an exception from the page (executed by chain.doFilter() on /examples/test.jsp for instance), then you cannot get the exception information in the error page configured in web.xml at this moment.
Here's the reason:
- You can set an error page like /WEB-INF/jsp/ErrorPage500.jsp for java.lang.Exception in web.xml, expecting you can use 'exception' variable in the error page as servlet spec says.
- But, because HstFilter swallows the exception as shown above, and it just invokes sendError(500), the error page cannot have 'exception' variable. FYI, if the error page was not triggered by an exception but by error status code, then exception variable is not available in the error page.
- Even if you don't use a custom error page, but use the default Tomcat ErrorReportValve, the default ErrorReportValve cannot report the exception traces at all if a filter shadows the exception.
This is inconvenient for web developers to trace subtle errors in any other servlet/jsp/filter code.
(The jsp example might look too trivial, but in reality, we can deal with many other application modules/framework integrated in site applications.)
Therefore, I'd like to suggest that we should throw a ServletException (wrapping the original exception) on both ContainerException and Exception, instead of sending 500 error now.