Scott T Weaver wrote:
Ate,
I thought I committed a patch to fix this as I was encountering the exact same symptoms. I committed this patch about a week, week-and-a-half ago to the HEAD.
You did: the NamespaceEncodedSession.java right? Well, in my local merge, I didn't touch that and still it didn't work. Furthermore, even if it worked, it wouldn't have solved the problems I encountered, ClassNotFoundException on deserialization of the portal session, because your solution only added a namespace layer around the same portal session. With my solution, this shouldn't be needed anymore although I didn't try to remove your wrapper code. I think we should test that out and if it isn't needed anymore, remove it.
Another reason why I definitely want a real separate session is that with Tomcat 5.5 a direct pa servlet invokation should receive the same session as when invoked through the portal. That is a very important feature required by the Portlet specs.
-scott
-----Original Message----- From: Ate Douma [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 23, 2005 4:10 PM To: Jetspeed Developers List Cc: Jetspeed Users List Subject: Re: [J2] merging the deployment_refactoring branch: start
A last update before I start committing my changes.
I've been delayed considerable today (most of it) as I found a serious bug in the way we handle cross-context dispatching (on Tomcat).
This had nothing to do with the deployment_refactoring branch but is something we probably have had all along.
Simply put: all (non-local) portlets share the session of the portal!
I found out about this because of the much better error handling and logging of Tomcat 5.5 when it tries to deserialize session state after a restart. There were several ClassNotFoundExceptions which wasn't so strange as it tried to load classes into the session of the portal which were private to certain portlets.
After debugging for hours I found out the cause. Under Tomcat (at least), cross-context dispatching will only result in a separate session (as required by the Servlet 2.3 specs) when the request object used for dispatching *is the original Tomcat request*. In J2, we wrap the original request inside our own ServletRequestImpl inside a PortletRequest and used it as well for the dispatcher.include call. This is part one of the problem. Part two is in the invoked JetspeedContainerServlet. There, we retrieve the PortletRequest (and PortletResponse) as saved as request parameters and use them to invoke the Portlet. But, inside is still the wrapped ServletRequestImpl, wrapping the original Tomcat request. That Tomcat request contains the original portal session. Solution part two: replacing the wrapped original Tomcat request inside the ServletRequestImpl with the new request received by the JetspeedContainerServlet. And viola: we have nicely separated session for each PA!
The ClassNotFoundExceptions at startup are now gone (at least: those related to this problem). And furthermore, hot redeployment of a pa doesn't cause the notorious ClassCastExceptions anymore either (JS2-155).
All in all, a lot of work to find out but I think as resolution a big improvement! The real credits have to go to the Pluto team though: only after looking at there solution did I find out how to solve it :-)
Ok. Let's get this over with: starting committing the changes within a few minutes!
Regards, Ate
Ate Douma wrote:
Just a short status update:
I've merged the branch locally and all seems to work as expected on Tomcat 5.0.28 I'll continue testing tomorrow morning for Tomcat 5.5.8 and JBoss 3.2.7. If that goes well too, I'll commit the changes. Now heading for bed :-)
Regards, Ate
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
