Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
...
IMO the use of both application contexts and service managers in the
tree processor is not such a good idea. It makes the code really hard to
follow, we should avoid mixed models in the same piece of code.
Absolutely; remember :) this is the first version which aim was to "just
work"; so removing all the Avalon based stuff should be the next step.
Hmm, here we need to discuss what we aiming for. Replacing our own ECM
with Spring for creating Avalon components is great as we don't need to
support our own container anymore. Giving users a better possibility to
use Spring for their applications is also great.
Giving us and them the possibility to mix Spring and Avalon setup in the
same block and even in the same component is less great IMO.
I agree to "within the same component"; I don't agree totally to "within
the same block" as you can use your own "legacy avalon" components in a
block while adding new spring based ones. Though I agree that these are
rare cases which should disappear over time.
There might be cases. If a block is so large that we don't want to
switch component management style in one go, it might be that the block
would better be split into several blocks.
It is enough work to learn to understand one component management system
for someone who want to contribute to a block. Needing to learn to would
be a rather forbidding threshold.
It would IMO be a step forward if we could replace most uses of
Serviceable with setter injection, this would lead to components that
are easier to reuse and test. But making a mechanical replacement of
ServiceManager with BeanFactory will be much work with questionable
advantages.
Agreed.
Also Spring configurations are not exactly easier to manage than our
current configuration files,
http://svn.apache.org/repos/asf/cocoon/whiteboard/butterfly/src/java/applicationContext.xml.
So before we run away and remove all the Avalon stuff we need to make
clear what we aiming for.
Exactly - now, I think we should not convert all of our stuff; the only
component I think were it makes sense to do it today is the tree
processor; this would imho clean up this code and make it even more
understandable for others.
I'd prefer if we start splitting up core in smaller parts before we do
such operations. The we can try the consequences of changing component
management in the tree processor in a branch first.
/Daniel
