Sharing session IDs across multiple contexts

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.

Good point.