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