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 "Peter Meier (JIRA)" <je...@jakarta.apache.org> on 2005/02/25 05:31:48 UTC

[jira] Commented: (JS2-210) Resolving all deployment classloader problems

     [ http://issues.apache.org/jira/browse/JS2-210?page=comments#action_59744 ]
     
Peter Meier commented on JS2-210:
---------------------------------

Ate,
When refactoring the deployment mechanism, will you consider auto deployment of PAs embedded in EAR files as well? If not, when will it be addressed?
Peter.

> 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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org