On 02/02/2010 00:10, Dan Armbrust wrote: > After content has been committed? > > Is there a proper way to write an error page, so that it will work > even when the response has already been committed? > > There seems to be a bug or 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: > > For example: > > <%@ page errorPage="unexpectedErrors.jsp" %> > > If the response has already been committed, then it just appends the > error page onto the end of the response (really ugly, but at least it > doesn't cause a secondary error) > > If the response has not been committed, it clears the buffer and > writes the error page (which looks nice and pretty , like it should) > > > So, in summary: > > 1) - Is Tomcats handling of an error page defined in web.xml broken > when a response has already been committed? Inconsistent? Yes. Broken? Maybe.
> 2) - Is there anything I can do to force the browser to a proper error > page after a response has been committed? No. Adding the error page to the end of the content is the best you can do but that is still a very fragile solution. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
