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

[Remy Maucherat]

Nick Lothian wrote:
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.
 

If you are basing your application on likelihood ... If you have three 
contexts involved and a large page (which has to happen somtimes, right 
?), then it will break.

The patch you're asking for is not that the included session should set 
a session cookie, but that an included page could set cookies. So remove 
the if (included) return; from the right method.

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

And they all have:
   public void addHeader(String name, String value) {
       if (isCommitted())
           return;
       // Ignore any call from an included servlet
>>>>        if (included)
>>>>            return;
       coyoteResponse.addHeader(name, value);
   }
An included servlet can do nothing which involves setting something in 
the response header.

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?
 

You cannot reliably expect it to work. It will use a large amount of 
memory, and is vulnerable to anyone calling flush, etc. What you'll get 
is something which would work most of the time if the application is 
well written.

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

Well, the normal request doesn't allow adding cookies when including. So 
the container has to unwrap and hope that the original request is there. 
The simplest way to allow this easily would be to remove the requirement 
that addCookie can't be invoked when including.

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.
 

One of the other issue I've found is that it attempts to specify the 
lifecycle of the session from the included context (ie, what happens 
when you invalidate it, and then what happens when you call 
getSession(false) again after calling invalidate). There's another issue 
as well, but it's less tricky.

Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]