cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: Cocoon Maven plugin - RCL goal refactorings
Date Fri, 22 Jun 2007 09:11:01 GMT
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
--------------------------------------------------------------------

Mime
View raw message