cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject RE: [Kernel22] How to develop a component?
Date Tue, 06 Apr 2004 15:37:31 GMT
On Tue, 2004-04-06 at 16:20, 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,

not every project uses Avalon either ;-)

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

Haven't thought deeply about this, but just some thoughts (without
choosing either way for now):

- for Cocoon-specific components (e.g. sitemap components) it doesn't
matter that much, except for the porting effort, both for us and for
users who have custom-developed components.

- for more generic components, one could argue that it should be easy
enough to write a wrapper component around it that implements the
correct interfaces. This for both directions, i.e. embedding non-Cocoon
components in Cocoon or embedding Cocoon-components in other locations. 

- This might be more difficult for components that don't stand on their
own but also have dependencies on other components, since then the way
in which component dependencies are resolved might be incompatible.

- Another problem might be that the Avalon interfaces are currently used
at a quite deep level inside Cocoon, not only at the component borders.

- But OTOH, if we start with interfaces which are clones of the Avalon
ones, porting that should be pretty straightforward.

- for embedding an Avalon-based application, one could also embed an
Avalon-container itself.

- If we're not going to use (or make) an Avalon container, in general
I'm also not convinced whether it's sane to still use the Avalon
interfaces.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


Mime
View raw message