cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Simplifying component handling
Date Tue, 03 Jan 2006 10:01:25 GMT
Carsten Ziegeler wrote:
> 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.

Oh yes, sure! And why not going back to the Director interface of the 
good old Cocoon 1.0 times?

Seriously, ECM++ allowed us to add new features that we badly needed 
such as xconf includes, and Spring bridge among others.

> 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.

Muhuhuhahahahaha! Nice documentation!!!! C'mon...

> I would suggest to either use constructor injectior or the Avalon interfaces but not
both at the same time.

Great, I suggest the same by using the Spring bridge.

> 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.

Just use Spring: this is compatible, and allows to move away from Avalon 

> 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....

Hmm... Is it April 1st already?

> 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.

I disagree: the migration path is to allow writing components *without 
caring about Avalon*. Any mixed model is a complexification as it 
requires to know both models and the interaction betwen them in mixed 
model components. And a nice documentation is not the solution.

> 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.

Right. And the simplest and most consistent step to go forward is IMO to 
just use what's already there, providing a nice bridge to a rock-solid 
container used by thousands of people.


Sylvain Wallez                        Anyware Technologies           
Apache Software Foundation Member     Research & Technology Director

View raw message