cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: springification of core
Date Tue, 09 Oct 2007 12:31:11 GMT
Giacomo Pati wrote:
> 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.
> 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?

Creating and testing cocoon components without instantiating Avalon (so 
no need for .xtest files). We could probably use standard cocoon 

<beans xmlns=""

   <!-- Activate Cocoon Spring Configurator -->

   <!-- Activate Avalon Bridge -->

It should instantiate only the block components and the components it 
depends on. After some work there should be no need to use 
<avalon:bridge/> either.

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

I removed Avalon interfaces.
>> 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.

same for me here.

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

Daniel indicated Configurable should be left untouched so people can 
configure the component from sitemap. I think it simply won't work as 
the springified components needs dependencies injected - it won't get 
those at the sitemap level.

Leszek Gawron               
CTO at MobileBox Ltd.

View raw message