Leo Simons wrote:
>I understand the problem (as defined previously). What I do not
>understand completely is how the proposed addition solves the problem.
>
>If I understand correctly, the addition of this method simply specifies
>that ComponentMetaData will provide a context based on the "parent
>context". What is a "parent context", exactly? It seems to me that
>introduction of a context hierarchy is actually a modification of
>framework contracts.
>
Specializations of a getContext method have the responsibility of
returning a context that (a) implements the interface type declared
under the ContextDescriptor metainfo, and (b) ensuring that the context
contains the set of targged and typed values. However, the clients
using the operation may want to ensure that supplimentary data is
container specific. Container specific information can be supplied in
the parent context value and used by the implemetation of getContext in
the construction of the final context value that is returned. This
approach (the method signature) enables the collaboration between a
client (such as a containerkit resource provider) and a getContext
implemetations. There isn't anything here that implies and change to
the framework notion of a context - the hierachical aspect only reflects
the implementation approach available in the framework when creating new
context instances (see DefaultContext ).
>
>
>Also, what will happen with this proposal in conrete implementations?
>Will containers (have to) extend ComponentMetaData and override the
>getContext() method?
>
Based on the proposed method implemetation - yes. Personnally I would
prefer to see at least a functional impleemetation of conformant context
creation - however - I think there will be insomountable problems in
getting that in place given the way containerkit evolution is being
controlled.
>
>Finally, it has been mentioned in earlier posts that this change will
>have big implications. Which implications are that?
>
There are several classes inside containerkit that do things like create
new instances of CompoentMetaData, ComponentInfo etc - and make
assumptions based on these classes. These two points make it more
difficult to use containerkit beyond the very basic metainfo and
metadata packages. For example, in the work I'm doing, because I am
dealing with components that will potentially need typed and poulated
context information, I have created a specialization of
ComponentMetaData (the Profile class) to hold this - (enabling complete
valation at the metadata level). However, specializing introduces the
problem that higher level sub-packages in containerkit are (a) treating
context as a special container specific concern as distinct from an open
extendble approach, and (b) due to the lack of support for the
declaration of ComponentInfo and ComponentMataData implemtation classes
that a container is using, many of the higher level facilities (such as
the containerkit kernel) become unasable.
1. Support for context from ComponentMetaData is what I'm asking for now.
2. Revision of AbstractResourceProvider would be required so that it
uses ComponentMetaData as part of its context resolution mechanisms -
this concerns a higher level package in containerkit and hopefully will
naturally migrate
3. Revisions to the API to support the declaration of specialized
implementation ComponentInfo and ComponentMetaData classes will be
something I will be raising later. Without this change the higher level
containerkit packages are not usable.
Cheers, Steve.
>
>Since I think I don't get it, I'm not voting just yet.
>
>best regards,
>
>- Leo Simons
>
>On Thu, 2002-07-04 at 20:12, Stephen McConnell wrote:
>
>>I would to propose the addition of the following method to the
>>ComponentMetaData class enabling the introduction of a Context value.
>>
>> package org.apache.excalibur.containerkit.metadata;
>>
>> import org.apache.avalon.framework.context.Context;
>> impost ...
>>
>> public class ComponentMetaData
>> {
>> //...
>>
>> public Context getContext( Context parent )
>> {
>> return parent;
>> }
>> }
>>
>>The purpose of the change is to ensure that (a) specializations of
>>ComponentMetaData can introduce their own mechanisms supporting the
>>creation and population of component data without forcing clients to
>>narrow to a particular class specilization in order to get the value,
>>and (b) ensure that Context is properly dealt with within the scope of
>>containerkit and that containerkit itself can be updated to use this
>>operation when aquiring the context value (as in the case with
>>Parameters and Configuration values).
>>
>>Here is my +1
>>
>>Steve.
>>
>>Stephen McConnell wrote:
>>
>>
>>>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]>
>>>
>>--
>>
>>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]>
>>
>
>
>
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
--
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]>
