portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <jetspeed-...@jakarta.apache.org>
Subject [jira] Commented: (JS2-210) Resolving all deployment classloader problems
Date Wed, 16 Mar 2005 17:19:20 GMT
     [ http://issues.apache.org/jira/browse/JS2-210?page=comments#action_60983 ]
Ate Douma commented on JS2-210:

I'll provide more information about the changes later but because I don't have time left for
today or tomorrow
I want to give the most important fact already now: JBoss (3.2.7) support.

Everything works fine under JBoss, except for isUserInRole(rolename). After a short investigation
I can say that
our current JAAS security layer will *not* work out of the box with JBoss (and probably neither
on several other
JAAS supporting application servers). I will come back on this later. Login etc does work
correctly though.

Here are the instructions for getting this branch working on JBoss 3.2.7 (I also tested 4.0.1
shortly and it seems
to work but I can't give it a 100% yet):

build jetspeed-2 for Tomcat (5 or 5.5) with:
  maven allClean allBuild quickStart

copy the contents of $TOMCAT_HOME/webapps/jetspeed into $JBOSS/server/default/deploy/jetspeed.war.

remove *all* commons-logging-<version>.jar and log4j-<version>.jar from both jetspeed.war/lib
as well as from
all the war files inside jetspeed.war/WEB-INF/deploy: 
  (jpetstore.war, jsf-demo.war, demo.war, pam.war, perl.war, php.war, security.war and struts-demo.war)
These jars will give classloader problems otherwise because JBoss provides them already through
a shared classloader. 

copy the contents of $TOMCAT/shared/lib into $JBOSS/server/default/lib (presuming $TOMCAT/shared/lib
was empty before building).

check $JBOSS/server/default/deploy/jbossweb-tomcat50.sar/server.xml:
- element DefaultContext attribute crossContext="true" (which is the default)

change $JBOSS/server/default/deploy/jbossweb-tomcat50.sar/META-INF/jboss-service.xml:
- <atttribute name="Java2ClassLoadingCompliance">false</attribute>
- <attribute name="UseJBossWebLoader">false</attribute>

change $JBOSS/server/default/deploy/jetspeed.war/WEB-INF/assembly/jetspeed-spring.xml:
- comment out entry "ApplicationServerManager" from bean with id "PortalServices"
- comment out bean with id "org.apache.jetspeed.tools.pamanager.servletcontainer.ApplicationServerManager"

copy jetspeed-ds.xml (or an adapted version like jetspeed-mysql-ds.xml) from the jetspeed-2
src folder portal/src/resource into $JBOSS/server/default/deploy.

copy your jdbc-driver (as configured in jetspeed-ds.xml) to $JBOSS/server/default/lib
(note: if you use the example hsqldb.jar setup of Jetspeed-2, you don't need to do this as
JBoss provides it already)

add *the contents* of jboss-login-config.xml from the jetspeed-2 src folder portal/src/resource
to $JBOSS/server/default/conf/login-config.xml

Happy testing ;-)

> Resolving all deployment classloader problems
> ---------------------------------------------
>          Key: JS2-210
>          URL: http://issues.apache.org/jira/browse/JS2-210
>      Project: Jetspeed 2
>         Type: Improvement
>   Components: Container, Deployment, Portlet Factory
>     Versions: 2.0-dev/cvs, 2.0-M2, 2.0-FINAL
>     Reporter: Ate Douma
>     Assignee: Ate Douma

> The current implementation of handling deployment, redeployment and undeployment of Portlet
Applications (PAs) contains
> several workarounds to prevent file locking of jars and classes on Windows and to allow
layout portlets to run under
> the Jetspeed-2 context.
> After almost a day debugging and testing I found the real cause of all the problems we
try to fix: 
> our own URLClassLoaders we create to be able to access the portlet and portlet resource
bundles in the PA.
> As a test, I replaced our own URLClassLoaders with the contextClassLoader from the PA,
retrieved during the init
> of the JetspeedServletContainer. And viola, no more problem!
> I'm going to drastically refactor the whole deployment implementation to be able to *only*
use the PA contextClassLoaders.
> The autodeployment from the deploy folder will be changed to infuse the PA war (if needed)
and *move* it to the webapps
> folder so the autodeployment of the application server will handle the real deployment.
> Thus: the undeployment from the deploy folder for PAs will be gone!
> Redeployment will still work as expected though.
> For undeployment, an new undeployment feature in the PAM Portlet will be added.
> Additionally, other PA management features like upload/start/stop/reload/ should be added
soon too. We need a separate
> issue for that though.
> Decorators (and soon layouts too) will still be handled as is done right now (they don't
involve classloaders).
> For deployment of layout portlets I want to make the following changes:
> - must be deployed as jar, *not* as war
> - can *only* contain classes, no resources
> - resources required by a layout portlet must be deployed separately with a decorators
or layouts jar
> - will *not* be deployed as web app but the jar *will* be loaded with a URLClassloader
with the portal classloader
>   as parent: the portlets will be invoked through a JetspeedContainerServlet from the
portal itself.
> These changes will also fix the outstanding problem with running Jetspeed-2 under a different
> (see JS2-172 and JS2-182)
> I'm going to need several days to perform this refactoring so if anyone has problems
with this plan please do comment within the next few days!

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
If you want more information on JIRA, or have a bug to report see:

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

View raw message