Niclas Hedhman wrote:
On Thursday 14 October 2004 05:23, Vadim Gritsenko wrote:
* Why new type of container is needed;
(I suppose: because some things are broken)
* What's broken in ECM;
* Why it can't be fixed in Fortress;
* Why Avalon compatibility can't be achived with new
container (so that you need second one in parallel).
An interesting thought that I have asked myself.
Looking at the 'container situation' today in Cocoon at the greatest detail, and one should soon realize that the "Pojo haven" is a bit misleading.
Let me elaborate;
Assume for a second that the Avalon Lifecycle contract was called the Cocoon Lifecycle contract and had no life outside of the Cocoon world. That contract specifies how the components are born, managed and killed within Cocoon.
Cocoon also has its own Configuration system and component declaration system.
Furthermore, there is something one could call a Request Cycle contract, the sitemap processing interfaces and the various XML chaining interfaces.
IMHO, the situation of component operations are far more complex than "Pojo will save the day".
I agree that a container is much more than Class.forName().newInstance(). But that's a container developper concern. The component developper should not have to care about this. She should just have to write the service logic of the component, all the management stuff being taken care of externally by the container. This is a separation of concern that POJO-based containers allow.
And that is probably the main reason why the Fortress effort 'stalled' ; Cocoon is so much more than dependency+conf injection.
Let me strongly disagree on this point. The Fortress effort stalled because the sitemap engine (aka treeprocessor) was intimately tied to some of the features of the ECM. The design choices of the container had slipped through into the component code. I am the culprit on this point. There was some refactoring of the treeprocessor lately that removes that dependency on ECM internals. It's still tied to Avalon framework concepts though, although it could be fairly simple to cut that dependency.
And I think the Spring/Pico camp is probably fooling themselves thinking otherwise. A Cocoon Pojo will not be easier to use outside the Cocoon environment than today's set of components are, since there are so many other things that needs to happen.
Agree. Cocoon core components are meant to be used into Cocoon. But Cocoon components should not depend on the container that hosts them.
IMHO, why not simply fork the ECM into Cocoon and mold it to the needs here? Add CDI and Setter injection into it, if people feel that is needed.
Why fork ECM if it's to turn it into a POJO container while there are mature ones already existing?
That would allow for a much smoother path for the majority of users. And as Stefano kindly explained to me...
Second principle of thermodynamics; Entropy of a system increases when the transformation is not reversible.
i.e. evolutionary steps of ECM are reversible, a leap-of-faith is not.
ECM evolution means still being bound to our current chains. Adding a level of Avalon framework compatibility to a POJO container means looking towards the future without ignoring our past.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
