cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: springification of core
Date Wed, 10 Oct 2007 08:13:40 GMT
Hash: SHA1

Daniel Fagerstrom wrote:
> 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.

Which AbstractLogEnabled are we talking about?


The cocoon one uses CL and is meant as a migration helper avay from Avalon's one.

> /Daniel

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

Version: GnuPG v2.0.7 (GNU/Linux)


View raw message