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 Tue, 09 Oct 2007 09:54:15 GMT
Hash: SHA1

Leszek Gawron wrote:
> Giacomo Pati wrote:
>> 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.


>>   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 -
Orixo, the XML business alliance -

Version: GnuPG v2.0.7 (GNU/Linux)


View raw message