cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Changes to the deployer plugin wrt shielded classloading
Date Fri, 17 Nov 2006 18:32:29 GMT
Reinhard Poetz wrote:
> One, to some extend, related question: Is it possible to have the 
> ReloadingClassloader in front of the ShieldingClassloader? Of course only at 
> development time.
Hmm, yes that should work.

> My goal is having a completly self-reloading Cocoon application that also 
> includes the block dispatching mechanism and not only at sitemap level. (As a 
> side note: We shouldn't consider sub-sitemaps as the number one way of 
> modularization in Cocoon anymore).
I think this side note is very important - and this remembers me about
my pending proposal to remove sub sitemaps completly.

> How could this be implemented? I think a servlet filter that sets the context 
> classloader of the current thread to the reloading classloader that delegates to 
> the shielding classloader should do the trick. 
Yes, that should work.

> Additionally it must be able to 
> reload the app context if any .class file has changed.
> The reloading classloader should be configureable so that it can put the 
> target/classes directories of other blocks onto the classpath. There should also 
> be some way to auto-generate this script.
> For COB-INF resources we could create a Spring configuration file that points to 
> the src/main/resources/COB-INF directories of blocks, again based on the 
> configuration file mentioned before.
In general this should work. I think we should all vote for the maven
war plugin patch,
to get the shielded stuff into the war plugin and continue from there.


Carsten Ziegeler - Chief Architect

View raw message