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)