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: DONE
Date Thu, 24 Mar 2005 00:28:28 GMT


Roger Ruttimann wrote:
> Excellent. Thanks for doing this.
> 
> I'll starting testing it.
> Any specific settings/configuration that is important to know ?
The only thing I can think of is making sure that your own psml files
now reference the layout portlets using jetspeed-layouts:: instead of jetspeed::
And if you want to test with Tomcat 5.5, just set org.apache.jetspeed.catalina.version.major
= 5.5
For JBoss, check out the last comments on JS2-210.

Regards, Ate

> 
> Roger
> 
> Ate Douma wrote:
> 
>> The deployment_refactoring branch is merged now and brings the following
>> features (in no specific order):
>> - actual pa deployment is now to be handled by the webserver itself:
>>   no more classloader issues
>> - J2 deploys on Tomcat 5.0.28/30, Tomcat.5.5.7/8, JBoss 3.2.7
>>   Tomcat 4 support is no longer available!
>> - For JBoss, the JetspeedDeploy tool can be configured to 
>> automatically strip
>>   commons-logging and log4j jars from the war
>>   (see the JBoss marked comments in the jetspeed-spring.xml in the 
>> assembly
>>    folder for configuration instructions)
>> - On JBoss, isUserInRole still doesn't work :-(
>> - On Tomcat, portlet applications can be started/stopped/undeployed from
>>   the new PorletApplicationManager portlet:
>>     http://localhost/jetspeed/portal/Administrative/pam2.psml
>>   Unregistration of non-local pa's (delete pa registry definition from 
>> db)
>>   is also available from this portlet on every platform
>> - PA Sessions are now really separate from the portal Session, solving
>>   lots of errors after redeploy and restart of the portal (JS2-155)
>> - The context under which J2 is deployed can now be configured at will
>>   (JS2-172, JS2-182)
>>
>> Maybe there are even more features/bug fixes in this update but right now
>> I can't think of more ;-)
>>
>> Happy testing.
>>
>> Regards, Ate
>>
>> Ate Douma wrote:
>>
>>> 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
> 
> 
> 
> 
> 


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