Summary: | ServletRequestListener.requestDestroyed is called before request leaves a webapp | ||
---|---|---|---|
Product: | Tomcat 7 | Reporter: | wheleph <wheleph> |
Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | major | ||
Priority: | P2 | ||
Version: | 7.0.19 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux | ||
Attachments: | Sample webapp demonstrating the issue |
Description
wheleph
2011-08-12 06:01:59 UTC
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. |