cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: [Kernel22] How to develop a component?
Date Thu, 08 Apr 2004 11:53:16 GMT
Sylvain Wallez wrote:

> 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 ;-)

Add some USD to this. I'd like Cocoon to support Avalon Framework API 
also. I don't understand why Avalon components could not be wired to be 
exposed by block.


View raw message