-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Leszek Gawron wrote: > Giacomo Pati wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> >> Daniel Fagerstrom wrote: >>> Leszek Gawron skrev: >>>> There is a lot of .xconf files in core. I would like to start >>>> converting them into spring beans >>> Great! >>> >>>> but question is: do we want that for 2.2? >>> Yes. >>> >>> It is a huge job to convert everything, so the only realistic option is >>> to do it incrementally, a couple of components at the time, when people >>> have time and feel like it. If we try to syncronize it with releases we >>> will never get it done. >> >> My experience with the sprinigication of CForms was straight forward >> and mostly mechanically as: > > Grzegorz, here's the guide you requested :) : > >> >> 1. move and migrate a component config snippet from the xconf file >> to the spring xml file >> 2. remove all imports of org.apache.avalon on the class under migration >> 3. fix the errors caused by 2. >> 4. migrate the configure method to setters (and adapt the spring xml >> accordingly) >> 5. migrate the service method to setters (and adapt the spring xml >> accordingly) >> 6. migrate the ServiceManager usage to setters (and adapt the spring >> xml accordingly) >> 6a. if 6. is too dynamic to be replaced by setters use >> BeanFactoryAware interface > > or use configurator:bean-map This only works as a ServiceSelectors replacements not for regular beans > >> 7. check if an ev. dispose/init method is still needed >> 7a. if those are needed use InitializingBean/DisposableBean (only >> singletons can be disposed) > > or use @init-method="initialize" and @destroy-method="destroy", which > approach do we prefer? I tend to use the attribute approach - one less > dependency on component framework. Ok > >> 8. restart at 2.for ev. base/abstract classes it extends > > You're right: springifying components is in most cases dead easy. I see > some problems in other area: springifying test cases for those > components. We need a fresh new SitemapTestCase for that. What is that SitemapTestCase good for? > > >>> 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? What you mean by "removed Avalon lifecycle"? > > 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? > > 2. Do we really need to keep Disposable, REcyclable if they have no > equivalent in prototype beans? They are Avalon interfaces so removing it would be the way to go. > 3. The only reason to keep LogEnabled is to allow user to set logging > category. I don't care about setting category. We once decided to move to Commons Logging, that should be enough. > > 4. The only interface that brings actual functionality is Configurable. > We should keep that as long as 1) works. I've replaced that with setter in the CForm springification. Works fine (or did I missunderstud?). > >>> You'll find a number of examples on how this can be done in >>> cocoon-pipeline-components. As users probably have tons of sitemap >>> component configurations in their sitemaps, I think it is reasonable to >>> give them some time to change. >>> >>> For non-sitemap components we have just removed the Avalon stuff. > > I'm starting with my favourite: continuations manager > - -- 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) iD8DBQFHC0/HLNdJvZjjVZARAiywAJwI6FeLXDsdq86cMNjmzbwLM0/MLwCgxpic gdFAQ5xks/mXpx7dThY4NNE= =MpEk -----END PGP SIGNATURE-----
