You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2010/02/03 00:07:30 UTC

DO NOT REPLY [Bug 48661] New: inconsistent error page behavior

https://issues.apache.org/bugzilla/show_bug.cgi?id=48661

           Summary: inconsistent error page behavior
           Product: Tomcat 6
           Version: 6.0.20
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Catalina
        AssignedTo: dev@tomcat.apache.org
        ReportedBy: daniel.armbrust.list@gmail.com


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.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


DO NOT REPLY [Bug 48661] inconsistent error page behavior

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48661

William Leung <lw...@21cn.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lwr@21cn.com

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


DO NOT REPLY [Bug 48661] inconsistent error page behavior

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48661

--- Comment #1 from Mark Thomas <ma...@apache.org> 2010-03-08 19:00:17 UTC ---
This has been fixed in trunk and proposed for 6.0.x

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


DO NOT REPLY [Bug 48661] inconsistent error page behavior

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48661

Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Mark Thomas <ma...@apache.org> 2010-04-07 20:44:20 UTC ---
The fix has been applied to 6.0.x and will be included in 6.0.27 onwards.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org