Nicola Ken Barozzi wrote:
>
> Stephen McConnell wrote:
>
>>
>> This message is to raise an important issue concerning containerkit.
>
>
> Which I see too.
>
>> The current containkit package defines the metamodel for a component.
>> According to the metamodel a component type are defined in terms of a
>> ComponentDescriptor, a ContextDescriptor, a set of 0..n
>> ServiceDescriptor entries, a set of DependencyDescriptor entries, and
>> finally, a set of LoggerDescriptor entries. These declarations are
>> the definitive description of a component towards a container. In
>> principal, any constrains declared here should be fully supportable
>> by any container. The mechanism supporting the instantiation of a
>> component defined by a ComponentInfo can be container specific.
>> However, containterkit declares a series of metadata type - these
>> types define information that is typically included in a container
>> application profile. It includes information about the configuration
>> to be used for a particular profile of a type or the parameters to be
>> applied to that type. Unfortunately, the metadata model (i.e. the
>> object model supporting the application level component instantiation
>> criteria) does not include the *context* that is required by a
>> particular component type profile. As some of you will have seen
>> already ... Pete and I have different view on this. The objective of
>> this email is to resolve that issue.
>
>
> ok.
>
>> One of two things needs to happen:
>>
>> (a) either the context related constraint information is removed from
>> ComponetInfo
>>
>> (i.e. we treat context the same way we treat configuration and
>> parameters - we guarantee an instance of Context and nothing more - and
>> document the implication of moving outside of this constract)
>>
>> or, (b) context information is included in ComponentMetaData
>>
>> (i.e. and we leverage existing Excalibur utilities that provide support
>> for this)
>
>
> I agree with the analysis.
>
>> Without a decision here we will never achieve a component validation
>> framework relative to containerkit. Components built using Phoenix
>> will not work inside other containers unless every container includes
>> specific context handling code. Contents built relative to Merlin
>> will work in Phoenix but only because Merlin will include the
>> extensions need to handle this constraint.
>
>
> The point IMHO is: are there constraints on contexts?
According to the specification of the metainfo in containerkit - yes.
(which I agree with).
>
>> Isn't containerkit the generalization of the container abstraction?
>> This is a serious issue - either we address the constraints we are
>> declaring, or, we make the hard and fast rule that any components
>> leveraging any typed context or is assuming the availability of a
>> context key must not be used if you want a component to be reusable
>> without resorting to a particular container. That constaint is simply
>> way too extreme. Irrespectivbe of a decision to support context
>> entries in containerkit or not, Merlin will deliver this support
>> basuase it is a fundimental to support of the Avalon framework
>> contract. I would prefer that we are up-front on this. If we declare
>> a framework related constraint in a container platform - we have to
>> deliver the tools to deliver management of that constraint. If not -
>> drop the constraint and let specific container implementations get on
>> with the job of doing real portable component management - and drop
>> the suggestion that containerkit is the common platfrom.
>
>
> What are the constraints that Context needs?
>
> Let me also be the devil's advocate again: what is Context for?
>
> ie is it good practice to do in contextualize(Context context)
>
> MYContext mc = (MYContext) context;
If the above form is recognized - then a context desciptor needs to
declare that the context must support a particular interface (which
ContextDescriptor currently does). If you look though usage of context
is the available component here at Avalon you will find this usage
pattern occuring frequently. If Context from framework was a final
class and not an interface then this would not be an issue. Context
isn't final - it's an interface and its often convinient to creeate a
specialized context (such as BlockContext or ServiceLoaderContext) to
ensure convinient and type safe accessors to context state members. So
given this flexibility that is already in the framework, a component
including the above source would need to declare in its metainfo that
the supplied context object must support MYContext interface.
>
> ?
>
> Or to do
>
> MYContext mc = context.get(MY_CONTEXT);
Which involves narrowing the Object regurted from get to a particular
type. Eg. a more typiocal example would be File file = (File)
context.get("home"); In this case the client is doing two things.
Firstly the client is assuming the the container will provide a context
entry with name "home" and secondly, that the context entry will be cast
to a type of java.io.File. Both of these constraint conditions are
correctly specified in the ContextDescriptor class in containerkit.
>
> ?
>
> The latter is done in Cocoon, and has created enourmous confusion to
> our users (of course, this is not an Avalon deficiency per se, but it
> shows how it has been used).
>
> Is it good practice to use Contexts to aquire common services?
> IMHO this is not so good, since it's recreating what Serviceable does.
Context and ServiceManager are different - a ServiceManager provides
"services" - i.e. a object reference to an interface matching a
particular version. A Context object provides key based access to an
"java.land.Object".
>
>
> As it seems now, a Context works as a common ServiceManager.
Not quite. Image a context object that contains the entry key "home"and
supplies a File instance. A File instance is not a service and cannot
be declared as a dependecy. The real difference is the issue of context
value creation versus service creation. Services are created using
component lifecycle patterns - context object don't follow this approach
and the result is Pete's earlier comment about null constructor
constraints. However, if you drop out of component land and think about
the issue in java land - the problems of context value creation is
manageble.
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]>
