[ http://issues.apache.org/jira/browse/JS2-210?page=comments#action_60016 ] Ate Douma commented on JS2-210: -------------------------------
I've created a new CVS branch, deployment-refactoring, in which I've committed my changes as of now. The current version is tested with deployment to Tomcat 5.0.28 and Tomcat 5.5.8 using JDK 1.4.2_04 for both. I've not added much comments in the code yet, nor committed with lots of messages as I wanted to get this into the branch ASAP. But, when (if) this branch is merged back into the HEAD branch I'll try to document it as much as possible. I'd like to invite all the developer team members as well as interested users to check this branch out and test it as much as possible. For sure it isn't complete/finished yet so I certainly expect issues to be reported :-) I did run the tests though and, except for two, all run without failure: - Most tests in TestSimpleDeployment I've commented out for now as I haven't had time to write new tests conforming the new deployment. - The TestSSOComponent failed on me when using HSQLDB with an SQLException (FK constraint violation), but not with Oracle9i. I haven't run the test with HSQLDB on the current CVS HEAD but I expect it to fail there too as this problem isn't related to the changes in the branch. Anyone going to test this branch should be aware of the following: - Decorator deployment isn't in place yet (I discovered tonight I forgot to write it). I already thought out how to implement it and I will try to provide a first version tomorrow. - Portlet Application undeployment (local or now) is not in place either, and isn't going to work the *old* way anyhow. This will have to be implemented within the PAM portlets and/or manager servlet like Tomcat has itself (offline unregistration directly through the database is also an option). - The decorator portlet application is now (locally) deployed under context jetspeed-layouts. This means that all the layout fragments in the psml documents now are changed. Like: jetspeed::VelocityTwoColumns -> jetspeed-layouts::VelocityTwoColumns Finally, you now can deploy Jetspeed under a different context! You have to configure this by hand after deployment (I'll add a build configuration for it later): - rename jetspeed.xml - rename context path="/jetspeed" and docbase="jetspeed" inside jetspeed.xml - rename jetspeed.war - rename $TOMCAT/webapps/jetspeed Thats all. Regards, Ate > 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 context! > (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: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
