You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2002/07/04 20:12:21 UTC
[VOTE] ComponentMetaData change
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:mcconnell@osm.net
> http://www.osm.net
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] ComponentMetaData change
Posted by Stephen McConnell <mc...@osm.net>.
Leo Simons wrote:
>On Thu, 2002-07-04 at 21:34, Stephen McConnell wrote:
>
>
>>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.
>>
>>
>
>gotcha #1.
>
>
>
>>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 ).
>>
>>
>
>IOW the contents of the 'parent' context are not specified inside the
>containerkit package, but rather it is specified that container
>implementations can provide and then make use of said such a parent
>context?
>
>So basically what you specify (ie contracts)
>
>public interface ComponentMetaData
>{
>
> /**
> * Implementations of ComponentMetaData will have to
> * provide a valid Context as per the component's
> * ContextDescriptor.
> * In addition to the ContextDescriptor, Containers have
> * the option of providing additional information in the
> * form of the useThis parameter. Keys, values and types
> * of useThis are left up to the container implementation.
> */
> Context getContext( Context useThis );
>}
>
>public class DefaultComponentMetaData
>{
> /**
> * The default implementation is really dumb. It is very
> * difficult to figure out how to specify context constraints
> * in a general way so our default implementation simply
> * requests that the Container building the metadata hand
> * an appropriate context.
> */
> Context getContext( Context useThis )
> {
> return useThis;
> }
>}
>
>and we'd have
>
>/** replaces Profile */
>public class SmartMetaData extends DefaultComponentMetaData
>{
> /**
> * Since Merlin is such a smart wizard, he was able to figure
> * out how to do something more sensible to create the
> * appropriate context.
> */
> Context getContext( Context useThis )
> {
> Merlin.castSomeCoolSpellAndDoMagic();
> }
>}
>
>Is that the proposal?
>
>
Yep - that's the proposal.
>
>
>>>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.
>>
>>
>
>Could you elaborate? Would it be possible to provide a satisfactory
>completely portable way of context creation? How would you do that?
>
Within the containerkit model - instances of ComponetMetaData are
created by a container is a container specific manner. The inclusion of
a ContextBuilder class within the containerkit framework would enable
container builders to leverage the level of portability offered by the
builder. The ComponetMetaData implementation could use such a builder
by default (the preferrable solution), or, specializations of
ComponetMetaData could use the context builder (but this will require
enhanced support in the containerkit framework for the nomination of the
specialized class to use). Concerning the implemetation of a
ContextBuilder (inside containerkit or Merlin) - I would base this along
the lines of the specification outlined in
http://marc.theaimsgroup.com/?l=avalon-dev&m=102564564305576&w=2
>I for one see context as something that by definition can contain just
>about anything, so that it by definition is not portable unless you
>modify framework.context. But I might be missing something.
>
>
The issue here is not what can a context object or contect value be -
but what is the constraints that a container implies with respect to
context and context value creation directives. This shifts the focus
away from the framework defintion of Context to the question of what is
the minimum support a container must provide if it is dealing with
portable components.
The approach I've described (based on the ContextFactory and related XML
schema) is one example of a degree of expressivement of what context
portability can be. It has technical limitations - but it it these
limitations balanced by container dependent support for context value
creation that will enable us to concretrely define practicle limitations
on component portability implies.
>
>
>>>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 ComponentMetaData, 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.
>>
>>
>
>IOW the lack of support for magic at the high level mean that providing
>magic at the specialized level means that the high level can be not/less
>reused? Yes?
>
>
I know what you mean but I having difficultly parsing the sentense!
There are two issues:
(a) getting the lower-level APIs right - e.g. the context question
and ensuring that higher level service in containerkit use this
(b) improving the openess and usability of containerkit services to
specializations of the core metadata model - For example - the
XMLInfoCreator class is hard wired to create a ComponentInfo class - is
also a final class - which means that any specialization of
ComponentInfo is forced to replicate the code base - or alternatively -
wrap a ComponentInfo instance is another class.
>
>
>>1. Support for context from ComponentMetaData is what I'm asking for now.
>>
>>
>
>+1 to the concept, you get that.
>
>
:-)
>
>
>>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.
>>
>>
>
>hmm. That seems to be the real issue.
>
>Looking at the containerkit package, I can understand why there is a lot
>of discussion. There are concrete classes without contracts that are
>used in validation of contracts.
>
>I would suggest we should start with defining contracts in the form of
>interfaces + javadoc, rather than in the form of implementations. I will
>kickoff in a separate thread.
>
>
Sounds good.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] ComponentMetaData change
Posted by Leo Simons <le...@apache.org>.
On Thu, 2002-07-04 at 21:34, Stephen McConnell wrote:
> 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.
gotcha #1.
> 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 ).
IOW the contents of the 'parent' context are not specified inside the
containerkit package, but rather it is specified that container
implementations can provide and then make use of said such a parent
context?
So basically what you specify (ie contracts)
public interface ComponentMetaData
{
/**
* Implementations of ComponentMetaData will have to
* provide a valid Context as per the component's
* ContextDescriptor.
* In addition to the ContextDescriptor, Containers have
* the option of providing additional information in the
* form of the useThis parameter. Keys, values and types
* of useThis are left up to the container implementation.
*/
Context getContext( Context useThis );
}
public class DefaultComponentMetaData
{
/**
* The default implementation is really dumb. It is very
* difficult to figure out how to specify context constraints
* in a general way so our default implementation simply
* requests that the Container building the metadata hand
* an appropriate context.
*/
Context getContext( Context useThis )
{
return useThis;
}
}
and we'd have
/** replaces Profile */
public class SmartMetaData extends DefaultComponentMetaData
{
/**
* Since Merlin is such a smart wizard, he was able to figure
* out how to do something more sensible to create the
* appropriate context.
*/
Context getContext( Context useThis )
{
Merlin.castSomeCoolSpellAndDoMagic();
}
}
Is that the proposal?
> >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.
Could you elaborate? Would it be possible to provide a satisfactory
completely portable way of context creation? How would you do that?
I for one see context as something that by definition can contain just
about anything, so that it by definition is not portable unless you
modify framework.context. But I might be msising something.
> >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.
IOW the lack of support for magic at the high level mean that providing
magic at the specialized level means that the high level can be not/less
reused? Yes?
> 1. Support for context from ComponentMetaData is what I'm asking for now.
+1 to the concept, you get that.
> 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.
hmm. That seems to be the real issue.
Looking at the containerkit package, I can understand why there is a lot
of discussion. There are concrete classes without contracts that are
used in validation of contracts.
I would suggest we should start with defining contracts in the form of
interfaces + javadoc, rather than in the form of implementations. I will
kickoff in a separate thread.
my vote for now, +0.
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] ComponentMetaData change
Posted by Stephen McConnell <mc...@apache.org>.
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:mcconnell@osm.net
>>>http://www.osm.net
>>>
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>><ma...@jakarta.apache.org>
>>>For additional commands, e-mail:
>>><ma...@jakarta.apache.org>
>>>
>>--
>>
>>Stephen J. McConnell
>>
>>OSM SARL
>>digital products for a global economy
>>mailto:mcconnell@osm.net
>>http://www.osm.net
>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] ComponentMetaData change
Posted by Leo Simons <le...@apache.org>.
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.
Also, what will happen with this proposal in conrete implementations?
Will containers (have to) extend ComponentMetaData and override the
getContext() method?
Finally, it has been mentioned in earlier posts that this change will
have big implications. Which implications are that?
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:mcconnell@osm.net
> > http://www.osm.net
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
> --
>
> Stephen J. McConnell
>
> OSM SARL
> digital products for a global economy
> mailto:mcconnell@osm.net
> http://www.osm.net
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] ComponentMetaData change
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
I have to say +0 for now...
I can't understand why the getContext() needs to take a parameter.
As I see it, the ComponentMetaData contains information about a
component instance, or all the data required to create a component.
I cannot understand why it needs a factory-type method. I thought
the ResourceProvider was supposed to handle that.
I am +1 for a
public Context getContext()
method, though, in line with getConfiguration() etc...
Stephen, could you be more specific why the method needs to be a
factory?
In particular, is it related to a standard factory that will initialize
the ComponentMetaData from an XML file and that you thus need to mix an
application specified context with the context data from the XML?
In that case, I'd vote for passing in the parent context into the
method creating the ComponentMetaData from XML.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>