Bug 4690

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!