cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: [RT] Building ECM++ for 2.2
Date Mon, 18 Oct 2004 12:29:03 GMT
Carsten Ziegeler wrote:
> The following idea came to my mind during the weekend. All the
> recent discussions about a new core/container etc. show that
> a possible future version of Cocoon will have a different
> component handling than we have now.
> One major concern for me is compatibility. It would be bad
> if someone had to rewrite his complete application just to
> update from one version of Cocoon to another. I guess we
> all agree on this. Now reaching this goal can be done
> from two sides:
> a) The new version can have a compatibility layer.
> b) We can provide a smooth transition from version to version.
> It would be ideal if we would have both. But with a compatibility 
> layer people tend to just use it without migrating their app.

And what is wrong with that approach (of just using it)? Beside community issues 
there were no technical issues which would force us to move people out of 
current component management infrastructure. Right?

> I wondered what we can do to build a better transition and
> to get users moving away from our current approach to a 
> newer version. A possible way would be to make minor improvements
> or modifications from version to version until we reach our
> goal. This could e.g. be done by building ECM++ for Cocoon 2.2.
> The basic idea is to build an own version of ECM, which is:
> grabbing the current ECM code, removing everything we don't
> need and build a complete container in Cocoon that provides
> the minimum functionality.
> This would be:
> - using the same configuration (roles and xconf)
> - provide support of the following avalon based interfaces:
>   LogEnabled, Contextualizable, Parameterizable, Configurable,
>   Serviceable, Disposable, Initializable, Startable

Ok, sounds good.

> What could be the benefit of this? 
> - no support for Composable, Component etc. anymore (so no
>   proxies and wired wrapping anymore).
> - no LogKitManagable, RoleManager support etc.
> - no Instrumentation support - we could our own instrumentation (JMX?)
> - All the code for this container would be ours - only the marker
>   interfaces are of course from Avalon.
> - We could easily add new features, like the selector handling
>   or the DI from Fortress. Using Fortress is imho out of question
>   as it does rely on too many third party code.
> By having our own container implementation we could add any support
> that we think that makes sense for providing a smooth migration path - 
> whereever this path ends :)
> Now, doing this is fairly easy; it requires just a bunch of code
> and would reduce our depencies while giving us more flexibility.
> I just started with this approach and could finish it in the next days
> if people think it is worth going this way. It would give 2.2 more meat
> as well.
> But perhaps this idea is totally foolish?

Sounds good with the only exception that I'm not sure about instrumentation vs 
JMX part. Anybody have ideas how Cocoon should be integrated with JMX? What 
management console we would use then?


View raw message