cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
Subject Re: springification of core
Date Tue, 09 Oct 2007 07:49:47 GMT
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

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


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

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?

3. The only reason to keep LogEnabled is to allow user to set logging 
category.

4. The only interface that brings actual functionality is Configurable. 
We should keep that as long as 1) works.

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

-- 
Leszek Gawron                         http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.


Mime
View raw message