cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Dependency on WebApplicationContext
Date Mon, 27 Feb 2006 19:25:37 GMT
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
>> Carsten Ziegeler skrev:
>>> Daniel Fagerstrom wrote:
>> ...
>>>> IMO the use of both application contexts and service managers in the 
>>>> tree processor is not such a good idea. It makes the code really hard to

>>>> follow, we should avoid mixed models in the same piece of code.
>>> Absolutely; remember :) this is the first version which aim was to "just
>>> work"; so removing all the Avalon based stuff should be the next step.
>> Hmm, here we need to discuss what we aiming for. Replacing our own ECM 
>> with Spring for creating Avalon components is great as we don't need to 
>> support our own container anymore. Giving users a better possibility to 
>> use Spring for their applications is also great.
>> Giving us and them the possibility to mix Spring and Avalon setup in the 
>> same block and even in the same component is less great IMO.
> I agree to "within the same component"; I don't agree totally to "within
> the same block" as you can use your own "legacy avalon" components in a
> block while adding new spring based ones. Though I agree that these are
> rare cases which should disappear over time.

There might be cases. If a block is so large that we don't want to 
switch component management style in one go, it might be that the block 
would better be split into several blocks.

It is enough work to learn to understand one component management system 
for someone who want to contribute to a block. Needing to learn to would 
be a rather forbidding threshold.

>> It would IMO be a step forward if we could replace most uses of 
>> Serviceable with setter injection, this would lead to components that 
>> are easier to reuse and test. But making a mechanical replacement of 
>> ServiceManager with BeanFactory will be much work with questionable 
>> advantages.
> Agreed.
>> Also Spring configurations are not exactly easier to manage than our 
>> current configuration files, 
>> So before we run away and remove all the Avalon stuff we need to make 
>> clear what we aiming for.
> Exactly - now, I think we should not convert all of our stuff; the only
> component I think were it makes sense to do it today is the tree
> processor; this would imho clean up this code and make it even more
> understandable for others.

I'd prefer if we start splitting up core in smaller parts before we do 
such operations. The we can try the consequences of changing component 
management in the tree processor in a branch first.


View raw message