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 }
