Pradip's question about lack of multipart support in another thread got me wondering about future features in the servlet spec. So, I grabbed a copy of Servlet Spec 2.5 and looked at the "What's New" section.
Although there is no mention of spec driven support for multipart request, it looks like they are adding some support for cross context sessions (or for the IDs anyway).
SRV.S.17 Changes Since Servlet 2.4 SRV.17.0.1 Session Clarification Clarified Section SRV.7.3, �Session Scope� to allow for better support of session ids being used in more than one context. This was done to support the Portlet specification (JSR 168). Added the following paragraph at the end of Section SRV.7.3: �Additionally, sessions of a context must be resumable by requests into that context regardless of whether their associated context was being accessed directly or as the target of a request dispatch at the time the sessions were created." Made the changes in Section SRV.8.3, �The Include Method� by replacing the following text: "It cannot set headers or call any method that affects the headers of the response. Any attempt to do so must be ignored." with the following: "It cannot set headers or call any method that affects the headers of the response, with the exception of the HttpServletRequest.getSession() and HttpServletRequest. getSession(boolean) methods. Any attempt to set the headers must be ignored, and any call to HttpServletRequest.getSession() or HttpServletReCHANGE LOG Final Version 287 quest.getSession(boolean) that would require adding a Cookie response header must throw an IllegalStateException if the response has been committe...
Since "How can I share sessions across multiple contexts" is one of our more common questions in this and the JSP forum I thought it was worth mentioning. Maybe someday contexts can become true pluggable components in a larger applcation.
The spec can be downloaded here. [ December 21, 2005: Message edited by: Ben Souther ]
I would interpret that to mean that I can use a single ID for all contexts. That way I wouldn't lose my session in context A just because I use context B later. It doesn't suggest to me that the sessions themselves would be cross-context (although it would make their implementation easier). But there'd still be problems because of different classloaders being used by different contexts.