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] Created: (JS2-210) Resolving all deployment classloader problems
Date Tue, 15 Feb 2005 21:33:45 GMT
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
 Assigned to: 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


Mime
View raw message