Bug 50793 - Invalid DispatchType in ServletRequestListener on async dispatch
Summary: Invalid DispatchType in ServletRequestListener on async dispatch
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Catalina (show other bugs)
Version: trunk
Hardware: PC All
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2011-02-15 22:47 UTC by Jeremy Boynes
Modified: 2011-02-27 22:37 UTC (History)
0 users

example using listener added to examples (2.64 KB, patch)
2011-02-15 22:48 UTC, Jeremy Boynes
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Boynes 2011-02-15 22:47:30 UTC
If a ServletRequestListener is defined, when is invoked after a call to AsyncContext#dispatch() the DispatcherType returned from the ServletRequest is REQUEST rather than ASYNC. When the actual servlet is invoked, the type is correctly set to ASYNC.

If the listener is intended to be invoked for each dispatch, then the DispatcherType should match the value returned in the filter/servlet.
Comment 1 Jeremy Boynes 2011-02-15 22:48:16 UTC
Created attachment 26663 [details]
example using listener added to examples
Comment 2 Jeremy Boynes 2011-02-15 22:53:39 UTC
Although invoking the listener on every dispatch strictly matches the Javadoc that says "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."

However, that is the same definition as used before async support was added. The methods on the listener (requestInitialized/requestDestroyed) make it sound like the event should occur at the start and end of the request lifetime.
Comment 3 Mark Thomas 2011-02-16 12:37:49 UTC
That was fun. It is always the simple looking bugs that are tricky to fix.

I agree that these events should be fired once per request. There was already some code trying to ensure that this was the case but it was ineffective.

I have fixed the problem and expanded the async test cases to cover this issue.

The fix is in trunk and will be in 7.0.9 onwards.
Comment 4 Jeremy Boynes 2011-02-16 22:37:16 UTC