Return-Path: 
 <dev-return-95253-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 35440 invoked from network); 22 Jun 2007 09:11:40 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 22 Jun 2007 09:11:39 -0000
Received: (qmail 19249 invoked by uid 500); 22 Jun 2007 09:11:42 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 19042 invoked by uid 500); 22 Jun 2007 09:11:41 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
List-Post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
List-Id: <dev.cocoon.apache.org>
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 19031 invoked by uid 99); 22 Jun 2007 09:11:41 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Jun 2007 02:11:41 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Received: from [88.198.46.98] (HELO indoqa.com) (88.198.46.98)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Jun 2007 02:11:37 -0700
Received: from [192.168.1.30] (chello062178239020.5.15.vie.surfer.at
 [62.178.239.20])
	by indoqa.com (Postfix) with ESMTP id CC0C82540C6
	for <dev@cocoon.apache.org>; Fri, 22 Jun 2007 11:19:30 +0200 (CEST)
Message-ID: <467B9225.60206@apache.org>
Date: Fri, 22 Jun 2007 11:11:01 +0200
From: Reinhard Poetz <reinhard@apache.org>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Cocoon Maven plugin - RCL goal refactorings
References: <467A8636.2000809@apache.org> <467B75DD.2090609@apache.org>
In-Reply-To: <467B75DD.2090609@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Checked: Checked by ClamAV on 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
--------------------------------------------------------------------