This message is to raise an important issue concerning containerkit.
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. 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) 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. 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. 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]>
