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. > > WDYT? 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 -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
