The session for a request is set according to the context in which the request originated. When a request is passed to a servlet in another context the session object should not be the same as in the original context. Looking at the code, it appears this boils down to having the context stored in the request reflect the actual context where the request is currently being processed. A mechanism also needs to be in place so that any sessions initiated in the second (or greater) context in the chain will have the same id as the session in the original context. This bug is present in the current CVS and was reported against tomcat and servlet 2.2 spec as well.
Created attachment 771 [details] my attempt to fix the problem, did not work do to use of Facade class
I checked the spec, and it seems you're right. I wouldn't categorize it as high priority, as I'm not a big fan of cross context access (for security reasons, plus I think that webapps should be as self-contained as possible). The patch appears far reaching and high risk, so it's not going in 4.0.x anytime soon (and will be documented as a known issue in all Tomcat 4.0.x versions which do have this problem). Waiting for Craig's opinion on this subject ...
This bug is complex to fix, and for this reason will probably not be fixed in the 4.0.x branch, but more likely for 4.1. This will be mentioned in the release notes.
*** Bug 8213 has been marked as a duplicate of this bug. ***
*** Bug 9116 has been marked as a duplicate of this bug. ***
*** Bug 10886 has been marked as a duplicate of this bug. ***
*** Bug 11879 has been marked as a duplicate of this bug. ***
*** Bug 13516 has been marked as a duplicate of this bug. ***
I hope someone can solve this problem, this is a serious problem to me, and I can't think of a solution to solve my problem other than using cross context. I working on a project which related to goverment policy. Therefore the application has to change every year (I mean the application calculation engine and the jsp page). Although it change to new year application, but the old application still has to stay alive for users who haven't migrate their data to new year application. Every year I have to deploy a new application and allow old application can cross context to talk to new application. Due to the session problem, the whole things cannot be done unless I change to another application server. Now is already version 4.1.18, this bug still haven't solve yet. Hope someone can consider this issue. My post in tomcat user mailing list: http://archives.apache.org/eyebrowse/ReadMsg?listName=tomcat- user@jakarta.apache.org&msgNo=95890
This will not get fixed in Tomcat 4.1.x. Spec people will have to assess the severity of the problem.
This should now be fixed. The fix will be included in 5.0.7.
While the new session is now being created and provided to the included resource, no cookie is being added to the response to allow the session to be retrieved when direct requests to the included context are recieved. (Pluto bug PLUTO-53 depends upon a fix to this issue: http://nagoya.apache.org/jira/browse/PLUTO-53) I have have attached a patch.
Created attachment 12542 [details] Cross Context Patch - Add Cookie if able to
I tried applying the specified path to 5.0.27 My portlet test still failed. The portlet's session ID was different than the servlet's session ID.
There have been two Servlet Spec versions and many more Tomcat versions since this bug was originally filed. Does this still matter to anyone, or at least to the original poster? Is the latest Servlet Spec (v2.4) clear on this issue? How is it handled in the latest stable Tomcat (5.0.28 at the time of this writing)? Who would object if this issue is closed as WONTFIX, since that's been the effective status for a year now?
I was the original poster and I obviously haven't been waiting 3 years hoping it will be fixed and I am less dependent on the cross-context behavior now than I was then. I simply filed the issue as a failure in the reference implementation to meet the specification. But there are others who are still suffering from this problem and many dupes were filed as well. Remy indicates that it should have been fixed, but it appears there is still a bug. The problem in Tomcat 4.x was deep in the architecture, but it sounds like a solution is closer at hand now, it would seem a shame to declare it a WONTFIX, if the current bug turns out to be simple. Resetting this to Tomcat 4 and declaring it WONTFIX while also entering a more specific defect report in Tomcat 5 might be a reasonable route though.
I would also object. The Portlet Specification depends upon cross context functionality working properly and there have been several complaints on the Pluto user and dev lists about this. I'm pretty sure that the underlying problem is in tomcat and not in pluto. As I stated before, the fix seems to be implemented halfway. The session which is passed to the target context is now unique, however, it is not permenantly associated with the context and thus can't be retrieved during future requests.
I completely disagree with this. The included session is merely a shadow of the including session. As a result, it will not be handled as an actual session with an independant cookie. This is not specified, so this is my interpretation, which should stand until crosscontext session lifecycle and behavior is actually fully specified.
Can you provide some insight on why your interpretation is that this session is a mere shadow? What use would a session be if it can't be retrieved later on for use by subsequent requests? Can you provide any ideas on how we can meet the requirements of the portlet specification's Application Scoped attributes (15.3) with your interpretation. I'm not necessarily a fan of cross context apps either, however, our issue is that we're trying to implement a specification which *seems* to require a different interpretation of the servlet spec than yours. Any help would be greatly appreciated.
I just voted for this bug and wanted to voice a comment as well. uPortal 2.3 and higher uses the Pluto JSR-168 portlet container in it's framework and is running into this bug as well. This issue is more pronounced in a portal environment since the abaility to share a session in the manner described in the bug is essential for a portlet to securly pass session scoped data to a servlet outside of the portal to initiate a download or similar action.
It's not my fault if the portal JSR decided to make asumptions about the servlet specification, and then, to be sure that they would piss off people, included their dubious asumptions in their TCK.
It seems to me that the only assumption that was made was that sessions would work normally when used from a cross-context dispatcher. Why is this such a dubious assumption?
I think this is an issue to be resolved between the Portlet Spec people and the Servlet Spec people. Tomcat's implementation is strictly according to the Servlet Spec, and is valid (passes all TCKs 100%) according to that Spec. IF the Spec specifies cross-context behavior that we don't support (it doesn't), then you'd have a legit Tomcat bug. If the Portlet Spec relies on behavior that is unspecified or unclear in the Servlet Spec, contact the JSR 154 team (jsr-154-comments@jcp.org) to address the issue. The Servlet Spec, like the Portlet Spec, is very much alive. I would not be surprised to see clarification on this cross-context stuff in v2.5 of the Servlet Spec. And needless to say, the next major Tomcat version will implement the next Servlet Spec version accurately and fully, just as it does now. But until such a Spec change is made, this is not a Tomcat bug.
This bug has been resolved through the patch referenced to below: http://nagoya.apache.org/eyebrowse/ReadMsg?listName=tomcat-dev@jakarta.apache.org&msgNo=80223 Anyone wanting to use this functionality must remember to set the "emptySessionPath" attribute in their connector configuration. An example is below. <Connector port="8080" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="8443" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" emptySessionPath="true" /> Many thanks to the Tomcat team for working with us to find an acceptable solution to all parties!