tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Lothian <>
Subject RE: Bug 4690: sessions not scoped according to spec section 7.3
Date Tue, 12 Oct 2004 00:24:28 GMT
> >
> >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.

I'm not quite sure what you are referring to. 

So far I have:
(a) Discussed this on the Pluto-Dev & Pluto-User lists. 
(b) Added a comment to issue
<> asking for
(c) Written the previous email to Tomcat-Dev, which in which I attempted to
state my case for having the behaviour changed. I apologise if it offended
anyone - in no way was it supposed to.

Another Pluto committer has written to & asking for clarification of the specifications. 

AFAIK all comments and discussions have been strictly technical at all

I don't see any politics there - we'd just like to get the issue cleared up
one way or the other. 

To be clear: If the JSR168 (Portlet) spec has to change I don't care - it
would just be good to be able to implement it properly.

> 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)

Okay. I can understand that argument.

It seems to me, though, that the proposed patch handles this, and that by
setting a sufficient buffer size the likelyhood of the response being
committed can be reduced.

I realize this isn't really a great solution because the behaviour silently
change depending on if the response has been committed or not. However,
there are plenty of other things in the servlet spec that behave in similar
ways (HttpServletRespone.addHeader, etc).

This change means there is a way to make sessions behave as would be
expected when used from a cross context request dispatcher. Currently that
is impossible, so wouldn't this be an improvement?

> - 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

Could you expand on this some? What internal object would the container need
to access?

> 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.

I'm sorry to hear that. 

I suspect that the Portlet specification suffers somewhat from "First
Version Syndrome" - there are a number of things that could be better
specified, and there are required bits of functionality that are missing.


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

View raw message