cocoon-dev mailing list archives

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

>Hi,
>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 
community.

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

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message