cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Concerns surrounding CocoonNG
Date Tue, 10 Aug 2004 14:32:17 GMT
Niclas Hedhman wrote:

>I have with great interest read just about everything regarding the Cocoon 
>sentiment of moving away from Excalibur Component Manager.
>What strikes me with the proposals 'on the table';
>  * Spring
>  * Pico
>  * Merlin
>  * Fortress
>  * Geronimo/GBean
>  * Custom (Kernel)
>is that AFAIU only Geronimo (not verified but assumed) and Merlin (verified) is currently
equipped to deal with hot & re- deploy of components.
>_IMHO_, such feature is far from rudimentary, primarily since it needs to deal with 'usage
references', i.e. decommission components that holds references to those that are being re-deployed.
>Since I belong to the 'Merlin camp', I sure am interested to hear;
>1. Is compatibility no longer an issue, and that a Cocoon 3 will emerge from a clean slate?
Or is a 'gradual' evolution from ECM to something new still the preferred approach?

Cocoon 2 was totally incompatible with Cocoon 1, and so could be an 
hypothetical Cocoon 3 (as not such plan formally exists today). 
Compatibility is of primary importance however for Cocoon 2.1.x series, 
and Cocoon 2.2 will remove what is being deprecated in the 2.1.x series.

>2. Is the Spring/Pico/Kernel camps considering classloading mentioned above being a non-issue,
and delegating the task to Cocoon itself to deal with it?

As I explained in an earlier post, there are two levels of containers:

- the single container for blocks, almost invisible from user code, that 
has to deal with hot deploy and classloading issues. In this category 
come Merlin, GBeans and our own Kernel

- the container within each block, managing application-level 
components, and thus visible to users. We use ECM for this today, and is 
where API-less containers such as Spring are studied.

>3. Is there interest in this community of a 'proof-of-concept', showcasing the powers
of Merlin, such as classloading, Jar management (Maven style), custom contexts, strong typing,
automatic dependency resolution and other features that Cocoon would benefit from?

Merlin certainly contains good code, but too many social issues for a 
small community. I don't want these issues to pollute the healthy Cocoon 

So my personal answer is no. Other people here may have a different 
opinion though.

>FYI, planned features for Merlin in the coming 6-12month period;
>* Better JMX integration.
>* JMS support.
>* JTA support.
>* IoC Type 2 and Type 3 dependency resolution.
>* JavaBeans/Type2 setter injection of parameter values.
>* User-defined life-cycles per component type.
>* Improved component-level security.

How's that different from GBeans+Spring?


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message