cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject [RT] Concerns surrounding CocoonNG
Date Tue, 10 Aug 2004 14:05:54 GMT

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?

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?

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?

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.

  /        /
 / / 

View raw message