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.
