You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Ate Douma <at...@douma.nu> on 2005/03/24 00:35:21 UTC
Re: [J2] merging the deployment_refactoring branch: DONE
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
Re: [J2] merging the deployment_refactoring branch: DONE
Posted by Ate Douma <at...@douma.nu>.
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
Re: [J2] merging the deployment_refactoring branch: DONE
Posted by Luc Fouin <lu...@free.fr>.
Roger Ruttimann a écrit :
> Excellent. Thanks for doing this.
++1, :)
> I'll starting testing it.
idem
--
Luc FOUIN - Stagiaire Aptiwan
14 rue Niepce
75014 Paris
Tél : 06 77 95 17 24
Mél : luc.fouin@aptiwan.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] merging the deployment_refactoring branch: DONE
Posted by Roger Ruttimann <ro...@apache.org>.
Excellent. Thanks for doing this.
I'll starting testing it.
Any specific settings/configuration that is important to know ?
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