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 12:31:11 GMT
Giacomo Pati wrote:
> -----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?

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


<beans xmlns="http://www.springframework.org/schema/beans"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:util="http://www.springframework.org/schema/util"
        xmlns:configurator="http://cocoon.apache.org/schema/configurator"
        xmlns:avalon="http://cocoon.apache.org/schema/avalon"
        xsi:schemaLocation="http://www.springframework.org/schema/beans 
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
                            http://www.springframework.org/schema/util 
http://www.springframework.org/schema/util/spring-util-2.0.xsd
                            http://cocoon.apache.org/schema/configurator 
http://cocoon.apache.org/schema/configurator/cocoon-configurator-1.0.1.xsd
                            http://cocoon.apache.org/schema/avalon 
http://cocoon.apache.org/schema/avalon/cocoon-avalon-1.0.xsd">

   <!-- Activate Cocoon Spring Configurator -->
   <configurator:settings/>

   <!-- Activate Avalon Bridge -->
   <avalon:bridge/>
</beans>

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                         http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.


Mime
View raw message