cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [Kernel22] How to develop a component?
Date Tue, 06 Apr 2004 16:16:36 GMT
Carsten Ziegeler wrote:
> Stefano Mazzocchi wrote:
>>>:) Sounds good to me. Now what do you think of using the 
>>things from 
>>>Avalon that are good (for us)? Now, I think, some of the interfaces 
>>>(for logging, contextualization, initialization) are good 
>>and we could 
>>>directly use them instead of building just a clone of them.
>>There are two issues here, Carsten. One is about the present 
>>and another is about the future. Present indicates that 
>>reusing what's available is great, future indicates that if 
>>we keep dependencies on
>>org.apache.avalon.* namespace we either end up forking it or, 
>>more likely, we have potential classloading collision issues 
>>in the future with things that avalon might produce.
>>remember the rhino classloading problem with weblogic? same thing.
> Sure.
>>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.

I don't buy this.

The "component portability" argument is moot, it's a myth, you can't 
even move components from one container to another in avalon and ECM is 
deprecated, now even fortress is deprecated.

Sorry, but the idea of a class-granular component is bullshit. APIs do 
that for you. want a portable parser? use JAXP. want a portable xslt 
transformer? use JAXP. want a object repository? use JCR.

The valuable component oriented paradigm is at the webapp level and 
there is no way you can reuse cocoon blocks in a container that is not 

At the class level, avalon components are normally a class thin wrapper 
around an API. And, if not, they soon migrate until they become that! 
It's not exactly something I would scream and yell if I had to rewrite 
in different containers.

> 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.

There will be an avalon sandbox for legacy code. There is nothing hacky 
in that.


View raw message