cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Some notes about the "Real Blocks" issue
Date Thu, 14 Oct 2004 08:47:10 GMT
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.

>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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message