cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: springification of core
Date Wed, 10 Oct 2007 08:13:40 GMT
-----BEGIN PGP SIGNED MESSAGE-----
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?

   org.apache.cocoon.util.AbstractLogEnabled
or
   org.apache.avalon.framework.logger.AbstractLogEnabled

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

> 
> /Daniel
> 

- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFHDImzLNdJvZjjVZARAia2AJ4pVO4EI/2zxat1BKASzlMZKwTuvwCfTVQO
j28H9DoDWmQiIVvrI00wI8A=
=rnER
-----END PGP SIGNATURE-----

Mime
View raw message