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?
> 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;
?
Or to do
MYContext mc = context.get(MY_CONTEXT);
?
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.
As it seems now, a Context works as a common ServiceManager.
:-?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
