Giacomo Pati wrote:
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.
You can either test with trunk or use the artifacts from the staging repository
(though you have to make sure that you don't have the old artifacts
org.apache.cocoon:cocoon, org.apache.cocoon:cocoon-maven-plugin,
org.apache.cocoon:cocoon-rcl-* in your repository):
<profile>
<id>cocoon-staging</id>
<repositories>
<repository>
<id>cocoon.staging</id>
<name>Cocoon staging repository</name>
<url>http://people.apache.org/builds/cocoon</url>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>cocoon.staging</id>
<name>Cocoon staging repository</name>
<url>http://people.apache.org/builds/cocoon</url>
</pluginRepository>
</pluginRepositories>
</profile>
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?
No I haven't removed that code neither in trunk nor locally and therefore
haven't been able to test it. But I think it's worth a try :-)
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?
It worked for me when I set up a seperate module that contains the interfaces
which are used to create a proxy bean instance from. Then I run 'mvn install' to
put the jar of the module into my local repo and added the dependency to the pom
of the project that uses the RCL goal.
That's not ideal but at least it makes it possible to use the reloading
classloader together with proxied beans.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
