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.
