avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject Container Abstraction (was RE: ContainerUtil)
Date Wed, 15 May 2002 17:11:17 GMT
> From: Peter Donald [mailto:peter@apache.org] 
> 
> I think this should be integrated into next layer up - I am 
> currently spending 
> most of my spare time working on that - mostly with myrmidon 
> stuff atm but 
> also with Phoenix and Fortress. 
> 
> Basically what I have now looks something like the following. 
> 
> Entry class: holds data required for an instance or "set" of 
> instances 
>              (in case of Poolables)
> ResourceAccessor: interface via which retrieve resources for 
> a particular
>             entry. (Like Loggers Contexts, ComponentManagers etc)
> LifecycleHelper: something that takes entry and accessor and "runs" a
>             component through its lifecycle

Ok.  My Handler classes mix LifecycleHelper and Entry into one.
The Container itself is what I have as a ResourceAccessor.

Question:
Is the ResourceAccessor able to be extended?  There are container
resources that I would like to pass from one a parent container
to a child container.

> 
> The above is the minimal construct and will allow you to 
> build DefaultFactory 
> in Fortress much easier and also will replace large chunks in 
> Phoenix, 
> Myrmidon (Embeddors in both projects will become much smaller and the 
> containers in each project will also shrink to minimal size).
> 
> On top of that I was planning of adding some different 
> services ontop of the 
> above stuff. Some of them don't belong in framework but some 
> will. Examples;
> 
> * utils to validate components (ie make sure all roles are 
> interfaces and that 
> no role interface extends a lifecycle interface)

:)

Cool!

> * utils to model metadata (if they can ever be abstracted well enough)

We need a place to start.  Lifestyle and dep/reqs are important
metainfo.  A container can ignore the info that it doesn't support,
but if the meta info is there we can pull it dynamically in a
consistent manner.

> * utils to enforce metadata model (like what is done in 
> phoenix now with 
> Proxies and all that)

Kind of like a BlockInfo checker?

> 
> So writing a container from then just becomes
> * writing something that "assembles" application (from one or 
> more config 
> files)

+1  So far we have several forms of that.

> * writing and plugging in extra services (like pooling, or 
> classloader 
> isolation or persistence or whatever)

That is core to the container itself

> * Writing the scaffolding code that glues all this together

Yep.

> 
> However this assumes that I actually find an acceptable level 
> of abstraction 
> which I am not so sure of atm ;)
> 

I think the key pieces of MetaInfo for a Component are:

* published interface (I.e. work interface).  In Phoenix it is called
the "service".

* interface version

* lifestyle info (is it threadsafe?, what is the minimal instance
policy?)

* requirements/optionals

* implementation version

The published interface is able to declare what the component
implements.
It is good design to only implement one interface--with the only
possible
exception being a compatibility layer (i.e. between different versions
of
a store interface).

The interface and implementation versions are used to reconcile what the
Container has available, and what is not.

The requirements/optionals pattern is established in Phoenix.  This
enables
the Container to give acceptible error information if the Component
cannot
be supported.  It also will make available certain optional components
if
possible.

Lastly, the lifestyle info--which I believe is where you are having
problems
coming to an acceptible abstraction.

The easy way to do it is to establish the creational policy, and give it
a
name:

pooled - Pool of instances (one instance retrieved per request)
perthread - One instance per thread
factory - Create/destroy instance for each request--is this necessary?
          Is the PerThread sufficient?
singleton - One instance to rule them all... One instance shared between
            all threads/requests

Perhaps a table?

attribute: | policy:
           | pooled | perthread | factory | singleton
-----------+--------+-----------+---------+----------
threadsafe |        |           |         |    X
-----------+--------+-----------+---------+----------
sharable*  |        |     X     |         |    X
-----------+--------+-----------+---------+----------
reusable   |   X    |     X     |         |    X
-----------+--------+-----------+---------+----------
perrequest |   X    |     X     |    X    |    X


*sharable - able to be shared between requests for the component,
            not necessarily sharable betweeen threads

The reason I have to ask about factory method is that if a "component"
instance cannot be reused, why is it created as a component?  There
are other more effective ways of dealing with those objects.

In essence the "perrequest"  is only needed if we want to support
factory--which I don't think is the most correct way of doing things.

Therefore, we can represent all important attributes in three
pieces of metadata.  It could be represented as a single piece of
metadata by representing the most restrictive creational metadata
possible.


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