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 faster.
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 -- Sylvain Wallez Anyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
