avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Mouat <rob...@mouat.net>
Subject RE: What is Avalon?
Date Sun, 23 Jun 2002 18:24:02 GMT
Leo Sutic wrote:

> I see three levels of increasingly more Magic in the container:
> 
> Single-component container (MicroContainer):
> Use in environments where you want to use an Avalon component
> in a non-Avalon program. See my separate mail about this.
> Big thing: No external metainfo.

I think I'd either want somthing lighter here, or add a forth (smaller)
layer...

What I'm thinking is more like a Component Abstraction Layer (CAL).  
Something like what is currently in ContainerKit (in particular the
LifecycleHelper) -- it would have methods that relate to component use
rather than deal with all the lifecycle methods individually (e.g.
startup() instead of compose(),parameterize(),initialize() etc.) -- also
while it would return an instance of the component, you would *never* call
lifecycle methods directly on the component (you would always go through
the CAL).

The CAL would *not* include things like a component manager or a component
locater -- you would need to provide these to the startup() method (or use
dummy/null implementations).  The Component Abstraction Layer is *not* a
container.

Then we can say to people:  "Use A4 components, and when you do use CAL4.  
And when we release A5, we'll update CAL4 so that it can handle A5
components, allowing you to use the A5 components without having to
rewrite any code"

Of course when A5 is released the CAL4 API probably wont be the best fit,
so CAL5 would be released at the same time -- and CAL5 works with both A4
and A5 components.

Only the Component Abstraction Layer would ever know if you were using an
A4 or A5 component.

It might even be possible to write the component abstraction layer so that
it supported non-avalon component lidecycles.

Robert.

> Embeddable Container (used to write blocks):
> For things like Cocoon. This is where Fortress etc. fits in.
> You have your metadata and so on, but the container is intended
> to be used inside something else - Tomcat, for example.
> Some external metainfo required.
> 
> Stand alone container (used to assemble blocks):
> Phoenix. Loads of metainfo.
> 
> /LS
> 
> 
> > From: Robert Mouat [mailto:robert@mouat.net] 
> > 
> > perhaps something like:
> > 
> > ContainerKit: utilities for handling a component that is 
> > written according to the framework (lifecycle, metadata, 
> > maybe custom markers, etc.).  Has a well defined API.
> > 
> > Fortress: embeddable (extensible) container, based on 
> > ContainerKit. Adds features that are useful for a container 
> > but don't affect the writing of a component (e.g. pluggable 
> > component managers, locators, interceptors). Uses 
> > programmatic configuration and assembly.  Has a well defined API.
> > 
> > Phoenix: server killer app, based on fortress.  Allows 
> > components to be configured and assembled via xml files 
> > without writing any code.
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
> 
> 



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