avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Date Wed, 20 Nov 2002 15:27:47 GMT
Paul Hammant wrote:
> 
> Carsten,
> 
> > Perhaps I had a wrong understanding of the different implementations
> > we currently have - I thought, it's not only the way how to
> > configure the components but also that there are some difference
> > in the features provided to implement components.
> 
> Implementation is one thing.  Lacing (lookup & assembly) and 
> configuration are another.
> 
> Imagine these abstract ideas :
> 
> 1) Servlet container (one design along A-F lines rather 
>          than Sun's established javax.servlet standard)
> 2) Bean container (as above)
> 3) Mailet container (apols to JAMES lurkers for rehashing old topics)
> 4) Newslet container
> 5) Gopherlet container
> 6) Portlet container
> 
> These comps all honor the usual interfaces - Startable, 
> Initializable .. i.e. our principal art.
> 
> Imagine that these comps come in their own packaging - WAR, EAR, 
> JAR with their own assembly
> manifests (web.xml, ejb-jar.xml etc).  
> 
> Imagine that these comps all have subtle differences in context - 
> BeanContext (as EOB does),
> ServletContext, MailetContext, GopherletContext.  
> Contextualizable passes in Context.  The comp
> casts it to the suitable sub-interface and uses its special features.
> 
> That's all for container-in-contrainer scenarios though.
> 
Hmmm, ok I understand this - and I (now) totally agree with you
here. But (sorry it's in my nature to write each second sentence
a 'but') these are containers for different purposes. You can't
use the newslet container implementation for portlets, e.g.
At this point I agree with you, but I would not agree if you
would have two portlet container implementations which are
configured (or their components) in different ways.

> <snip>
> 
> A-F interfaces make them compatible.  I have some workside 
> projects that use multiple containers
> (like those above) in one CVS tree for different run scenarios.  
> I assure you that A-F is the
> magic, not comp-lacing. And it is magic.
>  
It is, definitly! And I agree from a components implementor view
that's a very good solution (or better, the best solution).

Now, perhaps we are talking about the same things. Let's have a 
look at an example: I want to develop the coolest web publishing
framework in the work and of course I want to use A-F.
So far, no problems - now I choose to use Implementation A for this
which is configured via a configuration XML with format A.dtd.
After some time, I figure out that A does not scale under
some circumstances. 
Now I want to replace A with Implementation B. Unfortunately B
uses B.dtd for configuration and I have to rewrite my whole
configuration - so implementations are not easily exchangeable.

Carsten


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message