Bug 4690: sessions not scoped according to spec section 7.3

[Nick Lothian <ni...@essential.com.au>]

Issue 4690 <http://issues.apache.org/bugzilla/show_bug.cgi?id=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
same
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?

Nick
nlothian@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: Bug 4690: sessions not scoped according to spec section 7.3

[Remy Maucherat <re...@apache.org>]

Nick Lothian wrote:

>Issue 4690 <http://issues.apache.org/bugzilla/show_bug.cgi?id=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
>same
>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.

Rémy


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org