Re: On Multiple Containers

[Stephen McConnell]

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?

Yes.

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 here.
http://marc.theaimsgroup.com/?l=avalon-dev&m=103797075701365&w=2

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

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