Project: Tomcat
Bug 48661 inconsistent error page behavior
Reported: 2010-02-02 15:07:25 | Status: resolved fixed

There seems to be a bug or at least an inconsistency in how tomcat handles the error page. In Tomcat 6.0.20, if I define my error page like this in web.xml: <error-page> <exception-type>java.lang.Exception</exception-type> <location>/unexpectedErrors.jsp</location> </error-page> Then, if the response has already been committed, Tomcat does this on the system console: Feb 1, 2010 5:59:04 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet jsp threw exception java.lang.NullPointerException at org.apache.jsp.cpe_jsp._jspService(cpe_jsp.java:693) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.eaglecreektech.expedience.provisioning.web.servletFilters.AuthFilter.doFilter(AuthFilter.java:133) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.eaglecreektech.expedience.provisioning.web.servletFilters.RequestVolumeFilter.doFilter(RequestVolumeFilter.java:141) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.eaglecreektech.expedience.provisioning.web.servletFilters.StartupCheckFilter.doFilter(StartupCheckFilter.java:65) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:619) Feb 1, 2010 5:59:04 PM org.apache.catalina.core.StandardHostValve custom SEVERE: Exception Processing ErrorPage[exceptionType=java.lang.Exception, location=/unexpectedErrors.jsp] java.lang.IllegalStateException: Cannot reset buffer after response has been committed at org.apache.catalina.connector.Response.resetBuffer(Response.java:691) at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:409) at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:271) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:619) And it doesn't put any error text into the broken page - the page just shows how ever far it got before it encountered the error. This behavior doesn't seem correct - it seems like it should at least behave the same way as it does when the error page is defined in a jsp page: <%@ page errorPage="unexpectedErrors.jsp" %> If the response has already been committed, then it just appends the error page onto the end of the response (not ideal, but nothing else can be done, as far as I know) If the response has not been committed, it clears the buffer and writes the error page (which looks nice and pretty , like it should) I'd suggest that the error handling code for the error page as defined in web.xml should check if the response has been committed, and not try to clear the buffer if it is already committed - just append to the end, the same way that the jsp error handler does.

Files changed in fix:
java/org/apache/catalina/core/StandardHostValve.java