cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [Kernel22] How to develop a component?
Date Thu, 08 Apr 2004 10:09:10 GMT
Steven Noels wrote:

> On 07 Apr 2004, at 16:05, Nicola Ken Barozzi wrote:
>> Steven Noels wrote:
>>> On 07 Apr 2004, at 11:09, Nicola Ken Barozzi wrote:
>>>> The issue is not so technical as it's of indipendence from 
>>>> something that, in the good and the bad, has not helped Cocoon be 
>>>> built by Gump for ages now.
>>> As much as I like "Gumpinal Correctness" for the sanity of us Cocoon 
>>> committers, I'm not sure whether Gump has the goal of driving 
>>> architectural decisions for the projects it is aggregating 
>>> information from. It is a helper tool and should not decide for us, no?
>> Gump is deciding for us? Did I read "Gump wrote?" :-P
>> The fact is that a tool tells me that a project we depend upon does 
>> not get built regularly: this *does* impact on architectural decisions.
> The reason of Excalibur not building might perhaps be because of its 
> developers not caring enough about providing a strong contract to its 
> users. We have an established codeset and user base which have 
> habitually been adopting and using the Avalon *APIs* (I'm not 
> referring to a particular container here) because of (a) they found 
> out about them inside Cocoon, and were encouraged to use them for 
> their own Cocoon components, and (b) maybe they even started to 
> actually like them, and thus might expect us to provide identical 
> services and interfaces in our own container - backed by a healthier 
> community.

A big +1 here, also seconding Carsten. The Avalon *API* has led many 
people to COP, as this *API* provides simple means for a component to 
interact with its container. Sure, IOC type 2/3 make it more 
transparent, but IMO don't scale for large sets of components.

So although Cocoon will have a new container, it should not consider 
Avalon APIs as just a bunch of legacy interfaces that have to run in a 
sandbox. It's a slap in the face of many people that have invested time 
to build their application-logic components on top of an enabling 
infrastructure that was seamlessly integrated with Cocoon but could be 
used in other kind of apps, therefore allowing actual cross-application 
reuse of these components. Without this support, people are left alone 
without architectural guidance, and this will be a step back leading to 
unisolated spaghetti code.

So we can trash the ECM, we can change the configuration file format, 
but we *must* support (and not only as a legacy isolated sandbox) the 
Avalon framework APIs (a bunch of 1-method interfaces).

Cross-block classloading problems isn't an issue IMO, as it seems to me 
fairly easy to use dynamic proxies to translate calls to an interface to 
calls to the same interface in a different classloader.

My 1 euro. Yeah, a lot more than Steven ;-)


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

View raw message