cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: JXTemplate is broken by implementing Recycable interface
Date Wed, 10 Oct 2007 08:02:06 GMT
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
>> The bridge does, IIRC, the following: It parses the Avalon configuration
>> and create Spring bean configuration from it. It installs a bean
>> postprocessor that knows and reacts on the Avalon interfaces. And it
>> reads the newly created configuration.
> Yes, exactly - the spring bridge consists of these two parts. One for
> reading avalon style config and the bean post processor for managing the
> avalon lifecycle interfaces.
>> After this is done the bean post processor is still around and will used
>> on all other beans in the container.
> If they implement Avalon interfaces, yes.
>> Maybe the bean post processor could be turned of or removed after that
>> the Avalon components are processed? But I'm afraid that it isn't
>> possible. Lazy loaded beans and beans with other scopes (pooled). Might
>> need the bean post processor even after the initial load.
> I think for reloading and other stuff, you'll need the bean post
> processor. But I think we could check, if the bean processed by the post
> processor is one coming from the avalon configuration. So we could only
> apply the lifecycle interfaces if it is an avalon configured component.

Thinking a little bit more about it, this will create problems for the 
sitemap components that I have tried to make configurable both as an 
Avalon component and a ordinary Spring bean. Consider the file 
generator, it is a poolable component and will probably be served 
through some proxy that the Avalon bean post processor adds. But in the 
Spring configuration I made it a prototype scoped bean. As it has been 
like this for some time it seems like it works, burt I would guess that 
it consumes unnecessary resources.

> But I really think, if you develop a "plain" spring bean, that you
> shouldn't use any avalon interfaces.

Exactly, and I start to think that my suggestion that we should keep the 
Avalon configurabillity of sitemap components wasn't such a good idea. 
It seem to create more problems than it solves.

I suggest that when Springifiing components, we just remove the Avalon 



View raw message