avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: On Multiple Containers
Date Fri, 22 Nov 2002 14:24:07 GMT

Noel J. Bergman wrote:

>>My question was: why can't we agree on working toward *ONE*
>>implementation of the framework that fits everybody's needs
>This is a fair and valid question.  The answers ought to be technical and
>pragmatic.  I hardly think that anyone wants to disagree with that
>statement.  So lets make sure that replies are clearly technical.  Also, he
>has a point regarding community.
>>I'm not saying it's easy, I'm saying that it's the only way I see we can
>>resume the health of this community.
>His proposal for community building is to put everyone together to build a
>single container.  Because I don't believe that a single container
>implementation covers all requirements, and certainly not in the near to
>mid-term, my modification is that there be a single community, which is
>responsible for several containers.  Those containers must exist for real
>reasons, along the same lines as the various J2ME, J2SE and J2EE
>specifications.  Does that meet with approval as a reasonable approach?


>Nicola and Berin both acknowledge that convergence will take time.
>Understandable.  And I see that there are differences of opinion between the
>Phoenix and Fortress/Merlin groups on how to do certain things.  But someone
>please explain to me why it is not reasonable to do what code sharing CAN be
>done, and look at how to DECOUPLE THE DIFFERENCES, to maximize common code
>and make clear where the differences exist, and why.  Isn't this a
>reasonable approach to getting there?
>Consider my own examples of J2ME, J2SE and J2EE.  The reference
>implementations are not all written from scratch.  There is unique code
>(including cool things specific to a particular specification), and there is
>common code.  I think that this is a proven and reasonable model for
>resolving divergent needs, sharing common code, and freedom to experiment.
>It addresses every technical issue that I recall being raised, and does so
>within a unified community.
>Comments, please?  Berin?  Leo?  Nicola?  Paul?  Peter(s)?  Stefano?
>Stephen?  Anyone else with a container (or a view) whom I have neglected to
>mention in my alphabetized list?

I have been thinking about what an Avalon Framework Container API would 
look like on the assumption that it should serve as a framework for 
multiple containers.  I should quality this by saying that I see a need 
for multiple containers that are addressing different environments and 
usage scenarios.

The post I made earlier on this thread concerning 
service/type/profile/appliance management is part of my overall thinking 


This post is basically a continuation of those thoughts.

Things that can be separated out as part of a container framework 
include the following:

 1. logging management
     - logging system bootstrapping
     - logging channel creation
     - management of logging targets and priorities

Both Fortress and Phoenix provide support for application wide logging 
configuration based on the excalibur/logging package.  Merlin has a 
derived solution introduced due to the need to separate component level 
logging information (target and priority) from application level 
concerns on target creation.  The best solution in the long-term would 
be extension of the excalibur/logging package to include a formal meta 
model (negating the necessity for container specific solutions) that 
follows a common meta strategy.  A logging meta model would address 
definition of logging targets and an object model for describing logging 
categories and associated meta-data (category name, priority, etc).

 2. context management
     - context criteria management
     - context export from a container to a component
     - declarative context generation

Context management is something required by a lifecycle manager.  All 
Avalon containers deal with context in one way or another - the most 
typical being the supply of named values to a component based on 
container specific keys.  Merlin goes a little further with declarative 
constructs that enable programmatic creation of context values based on 
primitive container supplied named values, together with directive for 
object creation.  I would possible to define a context management 
interface and a default implementation that takes meta-info constraints, 
possible meta data, and container context, and from this, returns a 
context instance suitable for supply to a particular component instance.

 3. configuration management
     - classic configuration loading
     - default configuration handling
     - cascading configurations
     - verifiable configurations

Configuration management is also a concern of a lifecycle manager.  
Existing Avalon content is a little scattered around at this time.  
There is content in excalibur/configuration, some resources in Phoenix 
dealing with verifiable configurations, resources in Merlin dealing with 
default configurations.  In a similar manner to context management, it 
should be possible to define a configuration manager interface and 
default implementation that could be used across different containers.

 4. component assembly
     - building associations based on services and dependencies
     - validation of assemblies
     - assembly packaging

Component assembly is a part of the concern of a lifecycle manager.  A 
lifecycle manager basically needs to build a ComponentManager or 
ServiceManager that will be supplied to a component. Assembly strategies 
used in Phoenix and Merlin are similar at a conceptual level it that 
they both work off meta based information about dependencies and 
supplied services.  Fortress follows the ECM approach of demand driven 
runtime assembly.  These different approaches can be viewed as different 
assembly strategies - which could be addressed as alternative 
implementations of a assembly facility.

 5. lifecycle processing
     - management of the classic Avalon lifecycle
     - extension management

Lifecycle management involves the creation, deployment and destruction 
of components.  The creation of components requires a lifestyle manager 
(described below).  Beyond this, we have the classic Avalon stages 
(configuration, contextulization, servicing, initialization, etc.).  
These respective strategies can leverage standard stage managers 
(described above).  In the case of the "extension" model used in both 
Fortress and Merlin, this can be expressed as an implementation (or 
specialization) of a standard initialization manager/handler.

 6. lifestyle handling
     - management of object pools
     - per thread policies
     - named providers
     - transient components

Lifestyle handling concerns the policies applied to the instantiation of 
a component types.  It is a facility required within a lifecycle 
manager, and provides support for the semantics such as - per-thread, 
singleton, transient, pooled, etc.  Both Merlin and Fortress provide 
equivalent functionality in this area. A common lifestyle manager 
interface and implementation could be put in place and shared across all 
Avalon containers.

I have not addressed areas relating to classloader management, 
containment strategies, and security policy management simply because I 
consider these areas as less mature at this time.  I also think that the 
above breakdown isn't complete - but it a start.

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