Kludgy indeed. :) Just goes to show that there's *always* a way to get
things done if you're willing to jump through enough hoops.
If the client supported 302 Redirects, this wouldn't be such a problem as
the Filter could set the cookie in the redirect response and everything
would be fine. These requests that I'm dealing with are short XML messages
that should take very little processing time, for the most part, so
repeating the process by creating a new request with HttpClient would be
prohibitively expensive.
I think the best way to do this is to write a Filter that is also a
SessionListener. The SessionListener portion can keep an up-to-date
collection of HttpSession objects that are keyed off the sessionId. The
Filter could receive the request, parse out the sessionId, grab the
appropriate HttpSession from the local collection, wrap the request with an
HttpServletRequestWrapper that overrides HttpServletRequest#getSession() to
return the HttpSession that the Filter finds.
This shouldn't be too much of a performance hit, localizes all changes to
the Filter, and does so in a portable way. It means I have to keep a local
collection of HttpSessions, but that's not the end of the world.
Thanks for your insights,
justin
At 03:42 AM 10/15/2003, you wrote:
>Actually on second thought there is a klugdy workaround, you can create a
>Filter and trap the condition where the session does not come in the
>"normal way". From there, the Filter uses HttpClient (or appropriate) to
>construct a new request rewritten to be servlet spec happy. The downside
>is the CPU needs and network load is doubled.
>
>-Tim
>
>Tim Funk wrote:
>>You can't, you must use a Valve if you need to grab a Session from
>>another source than the standard spec stated ways. Any other servlet
>>vendor should have a similar answer. If they deviate from the above
>>answer, they lie.
>>
>>-Tim
>>Justin Ruthenbeck wrote:
>>
>>>
>>>A general Tomcat question, irrespective of Tomcat version or
>>>platform. Here goes...
>>>
>>>For Http requests, JSESSIONID values are passed to the server from
>>>either a cookie stored by the browser or an additional parameter
>>>included in the request. Tomcat creates the appropriate HttpSession
>>>object before control gets to the Filter and/or Servlet and makes it
>>>available via HttpServlerRequest#getSession(boolean). This is fine.
>>>
>>>I have a situation now where the JSESSIONID comes from an alternate
>>>source (encoded in the body of the message, for example). Custom code
>>>at the Filter level can parse the message body and find the
>>>JSESSIONID. Tomcat, however, doesn't know this and therefore does not
>>>grab the correct HttpSession and make it available through
>>>HttpServletRequest#getSession().
>>>
>>>Given the following constraints, does anyone have any ideas?
>>>(1) The client is not capable of understanding 302 (Redirect) responses.
>>>(2) No modification of *internal* Tomcat classes are possible. Usage of
>>>Tomcat specific Valves/etc. are possible.
>>>(3) If possible, Servlet code should not change. I would much prefer
>>>all logic to exist in a Filter (if not possible, this is flexible).
>>>(4) If possible, I don't want to maintain a separate collection of
>>>HttpSession objects local to a given Object.
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
>For additional commands, e-mail: tomcat-user-help@(protected)
____________________________________
Justin Ruthenbeck
Software Engineer, NextEngine Inc.
justinr - AT - nextengine DOT com
Confidential
See http://www.nextengine.com/confidentiality.php
____________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
For additional commands, e-mail: tomcat-user-help@(protected)
