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 Wed, 27 Jun 2007 12:13:41 GMT
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
>>>>>> 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
>>>>>> 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?


- --
Giacomo Pati
Otego AG, Switzerland -
Orixo, the XML business alliance -

Version: GnuPG v2.0.4 (GNU/Linux)


View raw message