cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: Cocoon Maven plugin - RCL goal refactorings
Date Fri, 22 Jun 2007 07:10:21 GMT
Hash: SHA1

Reinhard Poetz wrote:
> Before I'm going to release the Cocoon Maven plugin, I worked on the
> XPatcher for the web.xml. All .xweb snippets now get rewritten so that
> the ReloadingClassloader interceptors get applied to filters, listeners
> and servlets.
> As I was at it I also implemented a wrapper around the "normal" Spring
> web application context. It takes care of context reloads internally and
> is completly synchronized. Giacomo reported that he had problems when
> you accessed the Spring application context from outside of Cocoon, e.g.
> from within a servlet filter. This _might_ be helpful in that case
> though I haven't tested it yet.

I'll test it today, thanks.

> Since the reloads are done within the wrapper (--> the object instance
> doesn't change anymore), this might also make the app context reload
> check of the DispatcherServlet obsolete. Though I haven't tested this
> either because I ran all my tests with RC1 modules. Additionally it
> could help with Giacomo's problem too.

You say "might help too", does that mean it is still doing so or you have removed said code?

> Finally, I also ran into a problem if the application context contains
> proxied beans. If their interfaces are loaded by the reloading
> classloader, the application context refuses to work after a reload. I
> guess it is somehow related to the reloading classloader of commons-jci.
> As a workaround you have to put all those interfaces of proxied beans
> into a module which is not loaded by the reloading classloader.

Can you briefly explain how this is done?

Thanks and ciao

- --
Giacomo Pati
Otego AG, Switzerland -
Orixo, the XML business alliance -

Version: GnuPG v2.0.4 (GNU/Linux)


View raw message