cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: RCL goal refactorings / acegi
Date Wed, 09 Apr 2008 21:41:17 GMT
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        reinhard@apache.org
_________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message