cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Cocoon Maven plugin - RCL goal refactorings
Date Thu, 21 Jun 2007 14:07:50 GMT

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
--------------------------------------------------------------------

Mime
View raw message