-----BEGIN PGP SIGNED MESSAGE----- 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 - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (GNU/Linux) iD8DBQFGe3XbLNdJvZjjVZARArDTAJ0d/Je4sJM53OiJQfdVOTbKM/rSYQCfT91m uuk1/1qT2IHs817lH7omtVo= =LKcj -----END PGP SIGNATURE-----
