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 2011/08/12 08:01:59 UTC
DO NOT REPLY [Bug 51653] New:
ServletRequestListener.requestDestroyed is called before request leaves a
webapp
https://issues.apache.org/bugzilla/show_bug.cgi?id=51653
Bug #: 51653
Summary: ServletRequestListener.requestDestroyed is called
before request leaves a webapp
Product: Tomcat 7
Version: 7.0.19
Platform: PC
OS/Version: Linux
Status: NEW
Severity: major
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: wheleph@gmail.com
Classification: Unclassified
Created attachment 27379
--> https://issues.apache.org/bugzilla/attachment.cgi?id=27379
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
--
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 51653] ServletRequestListener.requestDestroyed is
called before request leaves a webapp
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51653
--- Comment #6 from Eitan Suez <ei...@gmail.com> 2011-11-04 17:13:36 UTC ---
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.
--
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 51653] ServletRequestListener.requestDestroyed is
called before request leaves a webapp
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51653
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Mark Thomas <ma...@apache.org> 2011-08-15 17:08:35 UTC ---
This has been fixed in trunk and 7.0.x and will be included in 7.0.21 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
DO NOT REPLY [Bug 51653] ServletRequestListener.requestDestroyed is
called before request leaves a webapp
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51653
--- Comment #5 from Stephan Maminakis <ma...@ensco.com> 2011-09-27 13:19:30 UTC ---
Thanks for the confirmation and the information update!
Stephan
--
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 51653] ServletRequestListener.requestDestroyed is
called before request leaves a webapp
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51653
--- Comment #2 from wheleph <wh...@gmail.com> 2011-08-15 17:35:46 UTC ---
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?
--
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 51653] ServletRequestListener.requestDestroyed is
called before request leaves a webapp
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51653
--- Comment #7 from Pid <bu...@pidster.com> 2011-11-04 21:01:37 UTC ---
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.
--
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 51653] ServletRequestListener.requestDestroyed is
called before request leaves a webapp
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51653
--- Comment #4 from Konstantin Kolinko <kn...@gmail.com> 2011-09-27 00:49:36 UTC ---
(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).
--
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 51653] ServletRequestListener.requestDestroyed is
called before request leaves a webapp
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51653
--- Comment #8 from Eitan Suez <ei...@gmail.com> 2011-11-07 17:31:41 UTC ---
(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.
--
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 51653] ServletRequestListener.requestDestroyed is
called before request leaves a webapp
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51653
--- Comment #3 from Stephan Maminakis <ma...@ensco.com> 2011-09-26 17:48:19 UTC ---
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
--
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