Doesn't this also fix JS2-261?
-----Original Message-----
From: Ate Douma (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 24, 2005 6:36 PM
To: [email protected]
Subject: [jira] Closed: (JS2-210) Resolving all deployment classloader
problems
[ http://issues.apache.org/jira/browse/JS2-210?page=all ]
Ate Douma closed JS2-210:
-------------------------
The new deployment implmentation has been tested and used without
problems for some time now.
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
Fix For: 2.0-dev/cvs, 2.0-M2
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is a PRIVATE communication.
If you are not the intended recipient, please do not read, copy,
or use it, and do not disclose it to others. Please notify the
sender of the delivery error by replying to this message, and then
delete it from your system. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
