tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: Bug 4690: sessions not scoped according to spec section 7.3
Date Mon, 11 Oct 2004 14:07:40 GMT
Nick Lothian wrote:

>Issue 4690 <> relates
>to the Tomcat implementation of cross-context sessions.
>The Pluto (JSR-168 Portlet RI) team need the behaviour in this area changed
>to be able to properly implement JSR-168. 
>I understand that this is an underspecified area of the servlet
>specification. I believe that this area will be more completely specified as
>part of the servlet 2.5 spec, which will be a good thing.
>In the mean time I'd like to suggest that the Tomcat interpretation of the
>spec isn't particularly useful, and that there are other interpretations
>that would be more useful, and equally as "right".
>Currently Tomcat's implementation of cross-context sessions means that if
>you put an attribute into the session from inside a cross-context dispatcher
>it cannot be retrieved.
>I would argue that:
>"Any object bound into a session is available to any other servlet that
>belongs to the
>same ServletContext and handles a request identified as being a part of the
>session." -- SRV.7.4
>indicates that cross-context sessions should be handled in the same way as
>normal sessions - particularly since the alternate interpretation makes
>sessions useless when used from a cross context  dispatcher.
>What do people think? Have I persuaded anyone yet?
What I see is that you have engaged in a widespread political campaign 
to have this changed, rather than rely on technical issues. I really 
hate this kind of tactic.

It should be extremely obvious that your little scheme relies only on 
the fact that you will be able to set cookies from an included resource. 
This is something which is unlikely to happen, given that:
- data is quite likely to have already been sent back (the response is 
now committed)
- the container might not have access to the internal objects from the 
request dispatcher, or at least it is rather hackish to try to access them

It might work fine for academic examples, but will likely fail in the 
real world. Overall, I have found the Portlet TCK to be full of 
asumptions on the Servlet API, even though these are on a very weak 
technical foundation. I have attempted to bring that up with the Portlet 
spec lead, with very little success.

-1 for this proposed change.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message