-----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-----
