cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <coc...@leverageweb.com>
Subject Re: [Kernel22] How to develop a component?
Date Tue, 06 Apr 2004 16:06:17 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.
> 
> 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?

I'm under the impression that this is very rare.  The constant fracturing of the 
container wars has to have made true interoperability very hard to achieve.  Are 
you saying that you have specific projects which use components across containers?

Existing components ought to be supported by the proposed avalon compatibility 
block.  Maybe new/updated components which need to interoperate with other 
blocks in Cocoon and with other containers could be constructed carefully to be 
valid components in both worlds.  A pain, but the universe of people who are 
likely to use both cocoon and other avalon components has to be a pretty small 
and capable group.

If this doesn't seem possible in your case, let's think about why and weigh our 
options.

Geoff

Mime
View raw message