> > > >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 <http://issues.apache.org/bugzilla/show_bug.cgi?id=4690> asking for clarification. (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 [EMAIL PROTECTED] & [EMAIL PROTECTED] asking for clarification of the specifications. AFAIK all comments and discussions have been strictly technical at all times. 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. Nick --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
