portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott T Weaver" <scotts-jetspeed-l...@binary-designs.net>
Subject RE: [J2] merging the deployment_refactoring branch: start
Date Wed, 23 Mar 2005 21:38:43 GMT
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:ate@douma.nu]
> 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: jetspeed-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> >
> >
> >
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message