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 Tue, 26 Jun 2007 09:52:38 GMT
Hash: SHA1

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.

Now here are my results: It doesn't work as expected!

java.lang.IllegalStateException: BeanFactory not initialized or already closed - call 'refresh'
before accessing beans via the ApplicationContext
        at org.acegisecurity.util.FilterChainProxy.obtainAllDefinedFilters(
        at org.acegisecurity.util.FilterChainProxy.doFilter(
        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(
        at org.mortbay.jetty.servlet.ServletHandler.handle(
        at org.mortbay.jetty.servlet.SessionHandler.handle(
        at org.mortbay.jetty.handler.ContextHandler.handle(
        at org.mortbay.jetty.webapp.WebAppContext.handle(
        at org.mortbay.jetty.handler.ContextHandlerCollection.handle(
        at org.mortbay.jetty.handler.HandlerCollection.handle(
        at org.mortbay.jetty.handler.HandlerWrapper.handle(
        at org.mortbay.jetty.Server.handle(
        at org.mortbay.jetty.HttpConnection.handleRequest(
        at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(
        at org.mortbay.jetty.HttpParser.parseNext(
        at org.mortbay.jetty.HttpParser.parseAvailable(
        at org.mortbay.jetty.HttpConnection.handle(
        at org.mortbay.thread.BoundedThreadPool$


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