avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: DTD compat -- red herring?
Date Tue, 20 Aug 2002 01:58:32 GMT

Nicola Ken Barozzi wrote:

> Leo Simons wrote:
> ...
>> In "my wisdom", current proposals are approaching a point where the
>> feature set, complexity, etc, is similar to the one the avalon lifecycle
>> propagates.
>> Sure, our lifecycle setup is not the fastest, nor is it the most
>> flexible, or manageable. The one killer feature of the avalon lifecycle
>> is that it is common ground (the other ones being that it is simple,
>> stable, documented, supported).
>> It has been shown that there is need for additional non-standard
>> lifecycle stages to <insert requirment here> write some components. To
>> keep these components portable across containers, the code that supports
>> the extension should also be portable across containers. To make that
>> happen we indeed need to make sacrifices, mainly feature flexibility.
> One note. The fact that there would be a common way to specify 
> extensions makes components portable.
> This is very important, and as you have seen you cannot use Cocoon 
> components OOTB, because it extends lifecycle.
> BUT...
> Is it true that we want Components to be portable across containers?
> If we have nested Containers, it seems (naively maybe?) that if we 
> want to use ComponentX in our ContainerY we can just make ComponentX 
> one of the components of ContainerY, and access the Components from 
> there...
> ie:
>  ComponentX-(hosts)- |--- ComponentX1
>                      |
>                      |--- ComponentX2
>  ComponentY-(hosts)- |--- ComponentY1 

Works in Merlin today.
Plus Merlin provides container lelvel classloader seperation.

> If I want to use ComponentX1 in ContainerY I do:
>  ComponentY-(hosts)- |--- ComponentY1
>                      |
>                      |--- ComponentX-(hosts)- |--- ComponentX1

Also work in Merlin today/.

> Which means that exery Component must be distributed with his Container.
> Isn't it conceptually similar to what Berin proposed with the 
> ****Manager stuff?
> Doesn't Merlin advocate a hierarchical Container system?

Yes it does.

Part of my overriding object was to establish a viable way of seperating 
different container semanitcis.  For example a Phoneix style container 
versus an ECM/Fortress style container - but preserve a single 
deployment context.


> Why can't we just build a common set of execution environments 
> (server-standalone ala Phoenix, commandline and Ant task ala Merlin1, 
> servlet embeddable... etc) and then populate it with the required 
> Containers (Fortress, Merlin2, Phoenix"Blocks", ECM)?
You can - it's called Merlin 2.0.
Populate it with the container you want, add components to the container 
that provides the quality-of-service your component needs.

Cheers, Steve.


Stephen J. McConnell

digital products for a global economy

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

View raw message