Patrick Heiden wrote:
Hello!
Sure. The Maven 2 plugin can be found at
http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-maven-plugin/. It
contains all the stuff that creates a small web application for a block so
that it becomes runnable in a servlet container.
The integration of the RCL is done by intercepting all requests (servlets,
servlet filters, listeners) and replacing the classloader with a reloading
classloader implementation. This code can be found at
http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-rcl/cocoon-rcl-webapp-wrapper/.
The third module is the spring reloader
(http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-rcl/cocoon-rcl-spring-reloader/)
that wraps a Spring context and performs the restarts of the Spring
application context whenever necessary.
This could be good starting point, because my error-messages are talking
about missing refresh-calls to springs appCtx. I will look...
Another hint that might help: When a class or an interface, that is loaded
by the RCL, is proxied or rewritten by Spring AOP, this leads to exceptions
after the first reload. I guess this is a problem with the RCL
implementation (Apache Commons JCI) but I haven't had time to write a test
case that proves this statement.
Apart from problems with Spring Security and Spring AOP, the third known
issue is session handling. If you put an object that is loaded by the
reloading classloader into the session, you will run into a class cast
exception after the first reload occured because the instance of the
reloading classloader has changed.
If you want to route around these problems, create a module that contains
all those classes that should not be loaded by the reloading classloader
and add it as a dependency to your module.
HTH
Yes, I would guess ;) But besides RCL, how would this
What does "this" refer to? If it refers to the list of know issues, then you
don't have to worry. The RCL stuff is only used when cocoon:rcl is invoked for a
Cocoon block. This Maven goal creates a web application that loads the block and
integrates a reloading classloader.
Using cocoon:deploy doesn't do any of these classloading magic. The only
exception is a shielding classloader that reverses the classloader hierarchy
(the web app context classloader becomes the first one) but it is turned off by
default.
look within a (e.g.)
Tomcat deployment, where RCL is not in scope. (I would love to test, but as
you can see at [1], I've actually got deployment troubles with Tomcat)
You could try to switch to the shielding classloader
(http://cocoon.apache.org/2.2/maven-plugins/maven-plugin/1.0/deploy-mojo.html
and http://cocoon.apache.org/2.2/maven-plugins/maven-plugin/1.0/1262_1_1.html)
which would load Xerces/Xalan of WEB-INF/lib with a higher priority those loaded
by the shared classloader of Tomcat or the application classloader.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair [EMAIL PROTECTED]
_________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
