You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2007/06/21 16:07:50 UTC
Cocoon Maven plugin - RCL goal refactorings
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
--------------------------------------------------------------------
Re: Cocoon Maven plugin - RCL goal refactorings
Posted by Reinhard Poetz <re...@apache.org>.
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
--------------------------------------------------------------------
Re: Cocoon Maven plugin - RCL goal refactorings
Posted by Reinhard Poetz <re...@apache.org>.
Giacomo Pati wrote:
> Reinhard Poetz wrote:
>> Giacomo Pati wrote:
>>> If you need some help just ask. Maybe I can snip up a sample. Would
>>> that be feasible?
>> yes, provding a minimal Spring Security sample would help a lot because
>> I've not used it yet. It would be great if you create the sample based
>> on the block archetype. Thanks!
>
> Ok, watch out for the commit of it _NOW_ :-) as I've already prepared a simple sample.
>
> It's not yet finished but if you launch it by 'mvn clean install jetty:run' and point you browser to
> http://localhost:888/cocoon-acegisecurity-sample/supervisor you should be redirected to a login
> page. Enter the cocoon/cocoon user/pw pair and afterward each request will give you aforementioned
> exception.
Thanks, that helps a lot! I can reproduce the problem but TBH I have no clue why
this can happen at all :-( AFAICS the app context is setup correctly but once it
gets used together with the acegi stuff, it complains that the app context is
closed.
I will have a closer look at it ASAP.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Cocoon Maven plugin - RCL goal refactorings
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Reinhard Poetz wrote:
> Giacomo Pati wrote:
>> If you need some help just ask. Maybe I can snip up a sample. Would
>> that be feasible?
>
> yes, provding a minimal Spring Security sample would help a lot because
> I've not used it yet. It would be great if you create the sample based
> on the block archetype. Thanks!
Ok, watch out for the commit of it _NOW_ :-) as I've already prepared a simple sample.
It's not yet finished but if you launch it by 'mvn clean install jetty:run' and point you browser to
http://localhost:888/cocoon-acegisecurity-sample/supervisor you should be redirected to a login
page. Enter the cocoon/cocoon user/pw pair and afterward each request will give you aforementioned
exception.
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)
iD8DBQFGgnKsLNdJvZjjVZARAlWkAJwPLLhJ8hyQqSStTcwSlaQLNpNAxACg6orv
nRsG9OENUxYEEaT97E24AYs=
=WlTo
-----END PGP SIGNATURE-----
Re: Cocoon Maven plugin - RCL goal refactorings
Posted by Reinhard Poetz <re...@apache.org>.
Giacomo Pati wrote:
> If you need some help just ask. Maybe I can snip up a sample. Would that be feasible?
yes, provding a minimal Spring Security sample would help a lot because I've not
used it yet. It would be great if you create the sample based on the block
archetype. Thanks!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Cocoon Maven plugin - RCL goal refactorings
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Reinhard Poetz wrote:
> Giacomo Pati wrote:
>> Reinhard Poetz wrote:
>>> Giacomo Pati wrote:
>>>> 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!
>>> That's strange :-(
>>>
>>> What do I have to do to reproduce it? Is writing another servlet that
>>> accesses the Spring application context enough?
>>
>> To be honest, I have no clue :-( I've simply configured acegi into the
>> web.xml (as a patch) and at
>> the second request mentioned stacktrace is thrown.
>
> I have never used acegi but will give it a try.
If you need some help just ask. Maybe I can snip up a sample. Would that be feasible?
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)
iD8DBQFGglR0LNdJvZjjVZARAqe2AKCnSiEwdtVSaVYxZLRXfCxQ9EugsACfW/PI
2L14UI4fRlqmlscWBglGOlY=
=JoxR
-----END PGP SIGNATURE-----
Re: Cocoon Maven plugin - RCL goal refactorings
Posted by Reinhard Poetz <re...@apache.org>.
Giacomo Pati wrote:
> Reinhard Poetz wrote:
>> Giacomo Pati wrote:
>>> 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!
>> That's strange :-(
>>
>> What do I have to do to reproduce it? Is writing another servlet that
>> accesses the Spring application context enough?
>
> To be honest, I have no clue :-( I've simply configured acegi into the web.xml (as a patch) and at
> the second request mentioned stacktrace is thrown.
I have never used acegi but will give it a try.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Cocoon Maven plugin - RCL goal refactorings
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Reinhard Poetz wrote:
> Giacomo Pati wrote:
>> 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!
>
> That's strange :-(
>
> What do I have to do to reproduce it? Is writing another servlet that
> accesses the Spring application context enough?
To be honest, I have no clue :-( I've simply configured acegi into the web.xml (as a patch) and at
the second request mentioned stacktrace is thrown.
- --
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)
iD8DBQFGgjMSLNdJvZjjVZARAjsjAKCqZQQkdKvp0are3fd8cKuXETk/bACg4EpZ
xnI7QKWgKHfql2QaDNb34jc=
=o0AN
-----END PGP SIGNATURE-----
Re: Cocoon Maven plugin - RCL goal refactorings
Posted by Reinhard Poetz <re...@apache.org>.
Giacomo Pati wrote:
> 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!
That's strange :-(
What do I have to do to reproduce it? Is writing another servlet that accesses
the Spring application context enough?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Cocoon Maven plugin - RCL goal refactorings
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
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.springframework.context.support.AbstractRefreshableApplicationContext.getBeanFactory(AbstractRefreshableApplicationContext.java:121)
at
org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:737)
at org.acegisecurity.util.FilterChainProxy.obtainAllDefinedFilters(FilterChainProxy.java:221)
at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:136)
at
org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingServletFilter.doFilter(ReloadingServletFilter.java:50)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:368)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
Ciao
>
>> 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)
iD8DBQFGgOHmLNdJvZjjVZARAsyAAKCX5cONk2yKv2Wgzx7lMWu4qzs4JACdFpLd
hSrilWT4qKV1vR0In/rnmpI=
=aRGD
-----END PGP SIGNATURE-----
Re: Cocoon Maven plugin - RCL goal refactorings
Posted by Giacomo Pati <gi...@apache.org>.
-----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-----