cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Some notes about the "Real Blocks" issue
Date Thu, 14 Oct 2004 04:06:04 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.

Agreed. At the same time, avalon's "interface fascism" is a little bit 
too much too.

> 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". And that is probably the main reason why the Fortress 
> effort 'stalled' ; 

One thing is for sure: cocoon used avalon when it didn't make sense.

> Cocoon is so much more than dependency+conf injection. And 
> I think the Spring/Pico camp is probably fooling themselves thinking 
> otherwise. 

I can't talk about Spring because I don't know much about it, but, with 
all due respect, Pico is just a (dangerous!) helper in constructing objects.

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

Very true. A cocoon pipeline component, for example, can be or cannot be 
an avalon component but you can't use it anywhere else.

At the same time, cognitively speaking, the importance of "it's just a 
pojo" is useful: people don't have to think they have to learn yet 
another thing to understnad what's going on.

> IMHO, why not simply fork the ECM into Cocoon and mold it to the needs here? 

Well, because when we are done there won't be anything left of ECM anyway!

You can fool yourself with Serviceable instead of Composable and shit 
like that, but the truth is: many many many times

  Generator file = new FileGenerator(src,handler,parameters);

would have been enough!!

> Add CDI and Setter injection into it, if people feel that is needed. 
> That would allow for a much smoother path for the majority of users. 

The one thing that I like about all this is how people finally 
understood how "class discovery" and "class construction" are different 
concerns.

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

Yes, I said that, but there is something I didn't mention to you about 
thermodynamics: sometimes substances undergo "phase transitions", when 
they change state.

Cocoon undergo phase transition when moving from 1.x to 2.x.

Are we doing it again?

The question on the table is: we *NEED* better class discovery and 
classloading isolation. This is a must, just like the need for SAX 
pipelines drove 2.x away from 1.x in a non-incremental way (phase 
transition, as I said).

Can we implement classloading isolation with incrementally modifying 
what we already have?

-- 
Stefano.


Mime
View raw message