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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
____________________________________ Justin Ruthenbeck Software Engineer, NextEngine Inc. justinr - AT - nextengine DOT com Confidential See http://www.nextengine.com/confidentiality.php ____________________________________
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
