|
It appears to me that when portal requests are being dispatched to portlets (which exist in an different context), Tomcat is not properly "changing" the session associated with the request.
Because of this, when a portlet puts an attribute in it's underlying HttpSession, in reality it's adding the value to the HttpSession coresponding to the original (portal) context instead of the portlet's context. Because of this, any subsequent request to a portlet resource which is not made through the portal's context (for instance anything which uses renderResponse.encodeURL() do not have access to the desired attribute. Interestingly, the Tomcat bug related to this was supposed to be fixed in Tomcat 5.0.7. I'm in 5.0.27 and am still having issues. For a test case try the "Application Scoped Session Attributes Test" which is now part of the pluto testsuite.
I've nailed this down to what I believe is a bug in Tomcat 5.x.
There was originally a bug reported in Tomcat 5.x in which requests were always returning the session associated with the original context and thus ignoring section 7.3 of the spec (which defines session scoping per context). This has been resolved - HOWEVER, no cookie is created when the included session is created/accessed for the first time. This results in subsequent requests (specifically those which come through the "target" (included) context) to create a new session. Please see: http://issues.apache.org/bugzilla/show_bug.cgi?id=4690 for a patch which can be applied to tomcat to resolve this issue. Hoepfully it (or a better fix ??) will be applied to Tomcat in the near future. This issue is not a Pluto bug. It appears to be a tomcat issue.
ReOpening until it can be confirmed. There are reports that the proposed patch for Tomcat does not work.
We are suffering from the same problem when using Pluto on Tomcat 4.1.29. We have a portlet application "HelloWorld" deployed in Pluto. When calling a Servlet within the HelloWorld directly using the /HelloWorld context path, we are not reaching the same portlet and/or HTTP session as if we access the portlet/servlet using the Pluto portal application.
Currently, the only way we could think of achieving the correct behaviour, is the following: - the portal application/portlet container (aka Pluto) and all portlet applications have distinct portlet and HTTP session, each having its own one. (PLT.15.2) - Pluto knows all sessions of all portlet applications - when a request to a specific portlet is sent to Pluto, Pluto redirects the request to the corresponding portlet application session (so that the request is executed in the context/session of the portlet application, not in the context/session of Pluto). Using the RequestDispatcher of the portlet application context("cross-context" feature) seems not to work as the Servlet then gets the context/session of the caller (here, Pluto). - when a portlet displays an URL that directly invokes a Servlet in a portlet application, Pluto has to encode the URL in a way that it points directly to the Servlet URL using the portlet application context path and that it contains the session id of the HTTP session of the portlet application as a jsessionid parameter. A patch has been applied to tomcat (Oct 13, 2004) which allows a work around for this issue. I think this bug can now be marked as resolved. If someone else can confirm that the patch works for them, please mark the bug as resolved.
Please see:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=pluto-dev@portals.apache.org&msgNo=1906 for more details. Mailing list has comfirmed that this works on Tomcat5.5. We now know that this is definately not a Pluto issue.
I see this issue has been closed because, in theory, this problem is not supposed to happen with Tomcat 5.5. However, I still see this problem using the RC2 binary release, which comes with Tomcat 5.5 as the servlet container. In fact, the test servlet ExternalAppScopedAttributeTestCompanionServlet, included with the testsuite app demonstrates this problem with RC2. Is this issue really fixed in Tomcat 5.5, or only in a later release of 5.5?
To correct my last comment, I forgot to also set crossContext="true" in the <context> tab. After doing this, I was able to verify that application level session information set in a portlet can be accessed by a servlet running in the same web applciation if the following things are all true:
1. The <context> tag sets crossContext="true" 2. The <connector> tag sets emptySessionPath="true" 3. You are using Tomcat 5.5.4, or later Of course, one thing that seems crazy to me is that I have to do these things when the portlet calling the servlet resides in the very same web app and, therefore, shares the same context path. IMO, JSR-168 does not make it at all clear what the proper context path for a portlet should be. That is, should the portlet take the context of the portal app where it's displayed, or the web app where the portlet's class is defined? I think these things need to be specified in much more detail. The issue seems not to be solved if you try to create a session from within a servlet being requested via the webapp context and afterwards try to request the portal with the same cookie/sessionid pluto returns a new session and the session attribute that was set within the first servlet call was of course not available for the portlet (although it resides in the same servlet context as the servlet from the first request) in the second request against the portal.
Please see the attachments added to clarify what happened. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
Pluto violates PLT.15.4
Please help.