Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <46820788.6020501@apache.org>
Date: Wed, 27 Jun 2007 08:45:28 +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>
 <4680E1E6.8040700@apache.org>
In-Reply-To: <4680E1E6.8040700@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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