[Bug 60385] ServletRequestListener.requestDestroyed not invoked after exception in requestInitialized

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60385

--- Comment #7 from Todd West  ---
(In reply to Mark Thomas from comment #6)
> There is additional specification language that supports Tomcat's
> implementation in the Javadoc for ServletRequestListener:
> 
> A ServletRequest is defined as coming into scope of a web application when
> it is about to enter the first servlet or filter of the web application, and
> as going out of scope as it exits the last servlet or the first filter in
> the chain.
> 
> 
> An exception in requestInitialized() will prevent the request entering the
> first servlet/filter so it can never exit it.
> 
> It probably wouldn't hurt for the spec to be more explicit on the expected
> behaviour here. I have no particular preference on what that should be but
> based on what the spec currently says, I believe that Tomcat's
> implementation is spec compliant.


Thank you for your reply, Mark. That's definitely understandable.

At the very least I think it's great to have this information documented here
so anyone else that runs into this issue can realize that it's working as
intended.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 60385] ServletRequestListener.requestDestroyed not invoked after exception in requestInitialized

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60385

Mark Thomas  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Mark Thomas  ---
There is additional specification language that supports Tomcat's
implementation in the Javadoc for ServletRequestListener:

A ServletRequest is defined as coming into scope of a web application when it
is about to enter the first servlet or filter of the web application, and as
going out of scope as it exits the last servlet or the first filter in the
chain.


An exception in requestInitialized() will prevent the request entering the
first servlet/filter so it can never exit it.

It probably wouldn't hurt for the spec to be more explicit on the expected
behaviour here. I have no particular preference on what that should be but
based on what the spec currently says, I believe that Tomcat's implementation
is spec compliant.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 60385] ServletRequestListener.requestDestroyed not invoked after exception in requestInitialized

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60385

Remy Maucherat  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #5 from Remy Maucherat  ---
Fix unintended status change.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 60385] ServletRequestListener.requestDestroyed not invoked after exception in requestInitialized

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60385

Remy Maucherat  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|REOPENED|RESOLVED

--- Comment #4 from Remy Maucherat  ---
JBoss EAP 6 does it like that. As I said, the other servers probably use a
try/finally, but Tomcat's implementation looks to be on purpose to do what the
javadoc says rather than shove the requestDestroy in the finally.
Anyway, have fun with your bug report, bye.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 60385] ServletRequestListener.requestDestroyed not invoked after exception in requestInitialized

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60385

Todd West  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #3 from Todd West  ---
I agree with your assessment of the issue but I have not been able to find
another app server the behaves this way. As noted in the report above I tried
in both Jetty and Glassfish and both of those servers responded how I would
expect, by calling requestDestroyed.

I can probably find a way to work around this issue but I figured it was worth
mentioning that Tomcat is the odd one out here as far as I've been able to
tell. If this behavior is expected and deviation from other servers is ok feel
free to close this out if you'd like.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 60385] ServletRequestListener.requestDestroyed not invoked after exception in requestInitialized

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60385

Remy Maucherat  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #2 from Remy Maucherat  ---
You're pretending to rely on behaviors that were never specified.

requestInitialized: Receives notification that a ServletRequest is about to
come into scope of the web application.
requestDestroyed: Receives notification that a ServletRequest is about to go
out of scope of the web application.

If there's an exception in requestInitialized, it probably doesn't come into
scope as per the javadoc language, so that's probably why Tomcat implemented it
this way originally. BTW, other servers do it like that as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 60385] ServletRequestListener.requestDestroyed not invoked after exception in requestInitialized

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60385

--- Comment #1 from Todd West  ---
For a little more information, the code involved in this issue can be found in
org.apache.catalina.core.StandardHostValve. Specifically in the "invoke(Request
request, Response response)" method.

When context.fireRequestInitEvent(request) is called, if it returns false (in
the case of an exception from a handler) then it will exit this method without
ever calling fireRequestDestroyEvent(request) to ensure that it can clean up
after itself.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org