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.
<snip/>
>
>
> 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
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
