portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: [J2] merging the deployment_refactoring branch: start
Date Wed, 23 Mar 2005 21:57:43 GMT


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: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
> 
> 
> 
> 
> 


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