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 Tue, 06 Apr 2004 20:07:06 GMT
Nicola Ken Barozzi wrote:

> Carsten Ziegeler wrote:
> ...
>>> I strongly suggest that we start with org.apache.cocoon.* to avoid 
>>> these problems down the road (including, yes, gump problems)
>> Yes, I understand of course all these problems, but I'm really afraid
>> of changing all the components now from Avalon interfaces to Cocoon
>> interfaces which are more or less the same but just use a different
>> package. In that case these components run in Cocoon but not in any
>> other container anymore that provides Avalon compatibility. And
>> that's imho bad. Not every project uses Cocoon, so it's absolutely 
>> preferable to have components that I can use in several projects.
>> Ok, I think if we decide to use our own versions of the interfaces it
>> will still be possible to do some hacky things and still provide
>> compatilibity with the Avalon versions.
>> So what do others think?
> Cocoon components will never work putside of Cocoon.
> Non-cocoon components should not use the Cocoon interfaces.
> I don't see the problem, as long as we don't mix all like we did with 
> Avalon.

IMO, the answer isn't so simple. A lot of people chose to use Avalon 
interfaces to implement component-based systems, especially for 
components related to business logic. These components can run inside 
Cocoon, but not only. And this choice was made possible because the 
COP-related interfaces are defined by outside of Cocoon, i.e. they 
aren't tied to the web tier in a more global architecture.

Now what if COP-related interfaces are defined within Cocoon? People are 
left alone to write their business-related components. This is a giant 
step back.

Also, I think the block kernel and ECM serve different complementary 
purposes. The kernel is useful to implement coarse-grained entities 
(blocks) that can be hotdeployed and hotswapped. ECM is useful to 
implement fine-grained entities (components) that need to be configured, 
eventually pooled, etc. But ECM-managed components aren't individually 
hotswappable (they don't need to).

So we can consider that there actually exists two levels of 
containement. Blocks are managed by the kernel, and components are 
managed by an ECM-type container, which, being part of a block is itself 
managed by the kernel.

This approach has the benefit of being an evolutionary path of what we 
have today and still allows people to benefit from COP interfaces to 
implement their own components, be them integrated into Cocoon or not.


Also, does someone know more about Keel (


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

View raw message