Created attachment 27379 [details] Sample webapp demonstrating the issue I use Tomcat 7.0.19, jdk 1.7.0-b147, Ubuntu Linux 11.04. Steps to reproduce: 1. declare error page for 404 code in web.xml 2. Set location of that page to some servlet (let's call it ErrorServlet) 3. go to any invalid URL in webapp (to cause 404) 4. ErrorServlet is called after requestDestroyed on any registered listener. This kind of behaviour is not correct in my opinion because it contradicts to contract of ServletRequestListener. Also it breaks org.springframework.web.context.request.RequestContextListener if ErrorServlet uses session-scoped beans. Description of the attached war file: 1. wheleph.RequestContextListener sets a local variable in requestInitialized and resets it in requestDestroyed 2. wheleph.SecondServlet writes to System.out the value of that variable thus showing whether it was called between requestInitialized and requestDestroyed or not. It's registered as 404 handler. 3. To reproduce the bug go to any invalid url (like http://localhost:8080/SpringListenerPOC/abcd) and see the message in log: "SecondServlet in scope: false" The relevant thread from dev.tomcat.apache.org: On 09/08/2011 20:55, Volodymyr Sobotovich wrote: > Hello, everyone. > > I think I have found a bug in Tomcat's lifecycle handling of > ServletRequestListener. I'd like to discuss it here before posting. > Tomcat 7.0.19, jdk 1.7.0-b147, Ubuntu Linux 11.04 > Steps to reproduce: > 1. declare error page for 404 code in web.xml > 2. Set location of that page to some servlet (let's call it ErrorServlet) > 3. go to any invalid URL in webapp (to cause 404) > 4. ErrorServlet is called after requestDestroyed on any registered listener. > This kind of behaviour is not correct in my opinion because it > contradicts to contract of ServletRequestListener. > Also it breaks org.springframework.web.context.request.RequestContextListener > if ErrorServlet uses session-scoped beans. > > What do you think about that. Should I post in to Bugzilla? Hmm. The error page handling is currently at the host level. One could argue the listeners are being fired in the right place (when processing enters/leaves the context). However, custom error pages defined by the web app are currently outside the listener calls and that doesn't seem right. Addressing this would mean either: a) moving the error handling to the context (inside the calls to the ServletRequestListener) or b) moving the calls to ServletRequestListener to the host level I am leaning towards a) but wondering why things are the way the are currently. I'd suggest leaving this on the dev list for other folks to comment and then add it to BZ in a couple of days unless the consensus is that it is not a bug. The next 7.0.x release won;t be until early Sept so there is plenty of time to get this right. Mark ======================================================================= Mark, On 8/9/2011 4:35 PM, Mark Thomas wrote: > Addressing this would mean either: > a) moving the error handling to the context (inside the calls to the > ServletRequestListener) or +1 This just feels like the right state management level to me. Certainly the default error handler can be called just as easily from this level of the code. -chris
This has been fixed in trunk and 7.0.x and will be included in 7.0.21 onwards.
Thanks for the prompt fix! I think it's also worth including in Tomcat 6 which is widely used now because this seems to be inaccuracy in implementation of Servlet specification. How do you think?
Mark, I have just upgraded from 7.0.20 to 7.0.21 and I think this resolution has affected a very simple error page that I have had in my web app since Tomcat 5. We have our own Realm which hits our Oracle database for the appropriate roles. I have the following in my web.xml: <error-page> <error-code>403</error-code> <location>/badaccess.html</location> </error-page> ... <security-constraint> <web-resource-collection> <web-resource-name>myadmin</web-resource-name> <description>My Admin Application</description> <url-pattern>/myadmin/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <description>System Administrators</description> <role-name>system_admin</role-name> </auth-constraint> </security-constraint> The badaccess.html page lives in my web app (war) and simply displays a nice message to the user, letting him know he is going to an off-limits page. Since I have upgraded to 7.0.21 this no longer works. Instead, I get the standard Tomcat 403 error page. Does the resolution to this issue require me to do something differently? Again, this worked fine up until 7.0.20. Thanks for any help, Stephan
(In reply to comment #3) > I have just upgraded from 7.0.20 to 7.0.21 and I think this resolution has > affected a very simple error page that I have had in my web app since Tomcat 5. You are correct that this fix broke error pages processing for certain error codes. In short, for errors that occur before request reaches Context. It has already been noticed and fixed. Will be in 7.0.22. (See changelog).
Thanks for the confirmation and the information update! Stephan
hello, i just upgraded a tomcat instance from v7.0.16 to v7.0.22. the webapp in question uses spring security for login/authentication. i noticed after upgrading that when triggering a logout using the spring-security-configured logout-url, i get this exception: ---------------------- SEVERE: Exception initializing page context java.lang.IllegalStateException: Cannot create a session after the response has been committed at org.apache.catalina.connector.Request.doGetSession(Request.java:2758) at org.apache.catalina.connector.Request.getSession(Request.java:2268) at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:899) at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:229) at org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:572) at org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:517) at org.apache.jasper.runtime.PageContextImpl._initialize(PageContextImpl.java:146) at org.apache.jasper.runtime.PageContextImpl.initialize(PageContextImpl.java:125) at org.apache.jasper.runtime.JspFactoryImpl.internalGetPageContext(JspFactoryImpl.java:112) at org.apache.jasper.runtime.JspFactoryImpl.getPageContext(JspFactoryImpl.java:65) at org.apache.jsp.error_jsp._jspService(error_jsp.java:57) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:389) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:593) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:530) at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:450) at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:399) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:191) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:405) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:964) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:515) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1550) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) ---------------------- i narrowed down the version: 7.0.20 -- no exceptions 7.0.21 -- i get the above exception my guess is that code changes relating to this issue somehow causes the spring security logout url (which the spring security LogoutFilter handles) to be interpreted as an error. After the LogoutFitler sends a redirect, tomcat's handling of the "error" request is somehow mucking with session after the response was committed. i wonder if the change introduced a bug or whether there's some configuration that perhaps i'm not doing properly on my end that could help me avoid this exception.
Did you just pick a bug at random and add your comments? Please join the Tomcat Users mailing list and ask for help there - Bugzilla is not a support forum.
(In reply to comment #7) > Did you just pick a bug at random and add your comments? > no. > Please join the Tomcat Users mailing list and ask for help there - Bugzilla is > not a support forum. ok; got it, thanks.