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.
-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]
