cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: springification of core
Date Tue, 09 Oct 2007 18:36:00 GMT
Leszek Gawron skrev:
> Giacomo Pati wrote:
>> Daniel Fagerstrom wrote:
>>> Leszek Gawron skrev:
>>> I don't know if we have discussed any policy for how to Springify the
>>> beans, but you will find many examples in the core. What I would propose
>>> is that for sitemap components, we keep and depricate the Avalon
>>> configurability and life cycle interfaces even if we Springify them.
> I was a little bit too fast and removed Avalon lifecycle from cocoon 
> template. Should I get it back?

I don't know. When I Springified sitemap components I just assumed that 
it would be a good idea to keep the Avalon configurability so that 
people doesn't need to change their sitemaps. But I'm not sure that it 
is worthwhile. Maybe it is better to provide some kind of update guide.

I would guess that most 2.1.x users has an enourmous amount of standard 
configured sitemap components in their main sitemap that is taken from 
the sample webapp. These configurations could just be removed in 2.2, 
the configurations included in the blocks will do the job.

What is more complicated are the sitemap components where users has 
customized configurations in sub sitemaps, here we need to provide 
migration instructions.

So the question is: should we keep the configurations basck compatible 
or should we ask users to update their configurations? WDYT?

> 1. Vadmin mentioned that if you have a springified component you have to 
> move it to spring context anyway because otherwise it won't work. Is 
> that correct?

No idea. I think it worked in Avalon mode when I updated some 
components, but I haven't checked since then.

> 2. Do we really need to keep Disposable, REcyclable if they have no 
> equivalent in prototype beans?

If we want to keep them working with the Avalon configurations that is 
necessary as the Avalon configurations doesn't include any information 
about that they should be prototypes.

> 3. The only reason to keep LogEnabled is to allow user to set logging 
> category.

And because some of the abstract base classes used for many of the 
sitemap components are based on AbstractLogEnabled.


View raw message