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.
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.
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.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
