cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [RT] Simplifying component handling
Date Tue, 03 Jan 2006 09:41:25 GMT
Addressing both, Sylvain's and Gianugo's response (at least partially):

Gianugo Rabellino wrote:
> It's not so easy. First let me state that I don't have any particular
> blocker if all we're talking about is adding constructor injection to
> ECM++: whatever goes in the direction of a lighter and
> less-Avalon-dependant Cocoon gets my applause. I do have issues,
> though, when mixing models. something we're very good at. Keeping both
> interface injection and constructor-injection (well, why not setter
> injection as well at this point, shouldn't be too hard and, hey, gives
> one more choice) and telling users to "take their pick" isn't going to
> work: adding features blindly not because of architectural/design
> issues but because it's tiresome to add 5 lines of code and - at the
> same time - not considering how users might be confused by the fact
> that we're still using Avalon but we're subverting its very principles
> is just not going to work.

Sylvain Wallez wrote:
> I have strong reservations about components using a mixed model (i.e. 
> dependency injection + Avalon interfaces), as these components will look 
> as "semi-POJOs" that bring some potential confusion about their lifecycle:
> - is the component ready after the constructor has been called?
> - what is the call order between setter-based injection and Avalon 
> lifecycle interfaces?
> - what is the lifestyle of a POJO: thread safe, single threaded?
> So although I'm all for a simplification of components and moving away 
> from Avalon, I'm strongly against using mixed models.
> Now, do we need to make changes to ECM++ at all? Cocoon 2.2 allows the 
> integration of other containers such as Spring (Carsten, _you_ wrote 
> that!), so we just have to *use* what is already there, using a solid 
> existing container rather than a half-baked solution.
Hmm, so why is ECM++ different from ECM (includes, JMX etc.)? With the
same argument we could just use ECM with the container integrations and
that's it.

Now, I'm only talking about constructor injection, so if you're using it
you have a well defined life-cycle of that component as the constructor
is called before everything else. Mixing constructor injection with
other Avalon interfaces might cause confusion, yes. It's up to the
component writer to decide this and we can come up with nice
documentation telling everyone how to develop components. I would
suggest to either use constructor injectior or the Avalon interfaces but
not both at the same time.
However, there is one exception: the lifestyle. As we can't agree on
making everything thread safe, I think the easiest way is to support
ThreadSafe, Poolable etc. with constructor injection as well - with the
default still being single threaded.
With constructor injection we have a simple container which is able to
serve POJOs while remaining compatible. And we are one step further in a
smooth migration path.
Setter injection is a different thing - I personally don't want to add
it as things imho get too complicated then (but if someone wants to do
it, well, why not).

And finally, Spring is cool and has nice features, but imho it has no
clean separation between a component writer and a component user when it
comes to configuration. In fact (as a teaser :) ), I'm thinking about
writing a new core for Cocoon based on Spring which supports annotations
and the avalon style configuration based on roles and xconf files. It's
not that hard to do, but the question right now is if it's worth it.
This could simply replace ECM++. But as we don't want to build on sand
again, I think this is out of question anyway....

Now, seriously, comming back to Gianugo's concern "adding features
blindly not because of architectural/design issues but because it's
tiresome to add 5 lines of code...": As I said, these changes make it
imho easier to work with Cocoon and provide a required migration path.
Imho, the best way would be to think about a new architecture/design for
a future Cocoon, build that and provide then migration paths. But the
last months have shown that we have currently no common understanding of
a future Cocoon - everyone has her own vision and plans. And as long as
we are in this situation, we can imho only try to do simple steps
forward and see where we will arrive.

Carsten Ziegeler - Open Source Group, S&N AG

View raw message