avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [proposal] Avalon Container Framework
Date Thu, 20 Nov 2003 18:21:01 GMT
Jonathan Hawkes wrote:

> This is a follow up to the threads: [RT] IoC Type Who Cares? [proposal] IoC
> type 3.14 extension to the Avalon Framework
> If you are coming into this discussion late in the game, you may want to
> review the above threads for more detail.

<snip type="implementation stuff"/>

There are some pieces that are missing from your overview.

The thing is that the container needs to know where it can find things.  In
order to do that, we have to specify how to resolve things within the kernel.

Meta data is very important, and all containers rely on it.  Some containers
rely on *implicit* meta data by defining the values for certain aspects of
the system.  Other containers are more flexible and let the user define the
meta data.  The critical thing here is not so much whether to have it, but
how to access it.

For instance, merlin has one meta model, that is fairly robust--but also very
well defined.  Fortress and ECM are examples where much of the metadata is
implied or assumed.

As long as we have a consistent interface to get metadata for a particular
class, I really don't care how it is implemented.  This will allow us some
flexibility in testing or pursuing new ways to store metadata.  It is the
mini-container (the small component container that you were outlining) that
needs to know how to resolve the information.

The second important issue is how to resolve other components.  As long as
we have a service type, we should be able to resolve based on what
implementations we have.  The "big" container (or kernel) will take care of
the best-match algorithm, even if that best match algorithm is based on an
assembly file.

Lastly is the subject of component configuration and container constants.
For this, the best approach I can think of is sort of a "registry" of sorts.
We need a way of automatically matching a configuration element to a particular
component, but once that is solved, the "big" container can take care of getting
all the components set up.

I suppose another point to concider is instrumenting the components.  For
example, if I want to know how long it takes to perform certain functions
on average, the container should be able to automatically add instrumentation
points on any publically accessible item.  Or even insterceptors on the method


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

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

View raw message