avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Tiered Container Hierarchy
Date Fri, 22 Nov 2002 08:29:58 GMT

Stefano Mazzocchi wrote:
> Berin Loritsch wrote:
> 
>> I would like to propose set of tiered containers and the appropriate 
>> compliance
>> test suites.  The approach requires all of us to work together 
>> (building community
>> as Stefano wants), and satisfies the real need for more than one 
>> container in
>> Avalon.  It would work something like this:
>>
>> 1) Micro Container--a Tweety like container that can operate in J2ME. 
>> It requires
>>   that only threadsafe components be used because it is unlikely that 
>> multithreading
>>   will be used in that environment.  It is severly limited, and 
>> identifies the minimum
>>   requirements for Avalon compliance.
>>
>> 2) Standard Container--the result of merging Merlin and Fortress.  It 
>> will be able to
>>   support embedding in a larger container (like J2EE) as well as the 
>> more robust
>>   component handling (pooling, thread-local, etc.).
>>
>> 3) Server Container--Phoenix.  It identifies the requirements for a 
>> root level container
>>   that hosts server applications.  It will not be embeddable because 
>> it is the kernel.
>>
>> I think that this approach will satisfy the community needs as well as 
>> the needs for
>> different types of containers.  It is also important to focus on 
>> container/component
>> contracts in each of these--all the while providing a reasonable 
>> default implementation.
> 
> 
> You would see me happy on this only if each container used the 
> underlying one.
> 
> That is: Merlin's Fortress is based on Tweety and Phoenix is based on 
> Merlin's Fortress (can we come up with a better name for this, please?)
> 
> That would solve all my concerns and would force people to work together 
> and create a community because they would share not only the syntax and 
> the semantics but also the behavior. And would force all containers to 
> keep in synch.

Something between these lines had been proposed in the past months and 
probably also before. Look in the CVS dirs and there is a microcontainer 
somewhere.

Currently the picture is a bit different: we have Excalibur that keeps 
common stuff for all these containers, that pick what they prefer.


               ,----------  Tweety
              |
  Xcalibur  --------------  Merlin
              |
              |-----------  Fortress
              |
               '----------  Phoenix


In fact IMHO it can be done with what we have now.


       Phoenix
          |
         Owl (Merlin's Fortress)
          |
       Tweety


There is no need to merge the excalibur packages in each container, but 
we could make the featureset be layered and have each container just 
enhance from the previous.

That's why I started the info-meta merge discussion, and see clazz as a 
good solution. That's also why I would like that Phoenix developers and 
Merlin-Fortress ones work closely to create a common metamodel, since 
Phoenix, in this view, would inherit from "Owl".

> [note that this reflects the inheritance model of OOP which this very 
> community seems to have forgotten since Avalon doesn't make extensive 
> use of it]

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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