You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2002/07/04 23:42:24 UTC
Component Metadata and Metainfo model
all,
we have determined there is a need for a common object model to
represent metadata and metainfo for avalon components. This to allow for
portability of said components across containers.
This object model has to be formalized in a way quite similar to the
framework lifecycle, hence it is currently partially in the same
excalibur module: containerkit.
Definitions
-----------
metadata - basic definition: MetaData is everything that has to be
provided to a component by its container in order for the component to
function properly.
metadata - avalon definition: MetaData is the assembly of object
instances of a components declared dependencies on other components, as
well as dependency on a Logger, Configuration, Parameters and Context.
metainfo - basic definition: MetaInfo is a complete description of
MetaData. Complete MetaInfo can be used to generate complete MetaData.
metainfo - avalon definition: MetaInfo is an assembly of descriptors of
a components declared dependencies on other components and on a Logger,
Configuration, Parameters and Context, as well as a container for some
human-readable information about the component.
note: metadata and metainfo is partly provided by java itself, primarily
in the form of the Class method and related (ie Method). Additional
standard metadata and info is provided in the form of descriptors first
introduced with JavaBeans, where the information provided by Class is
expended by providing an optional <<classname>>BeanInfo class. Other
specifications like JMX expand on this (JMX has the option of providing
a class extending MBeanInfo).
current situation
-----------------
ECM is a bit of a mess wrt to metadata/metainfo. Phoenix allows
specification of metadata through <<classname>>.xinfo files, as well as
through xml configuration. Merlin partially allows the same
configuration, and does some smart automatic determinition where an
xinfo file is not provided.
Suggested interfaces
--------------------
This builds upon the current avalon containerkit package. Please don't
worry too much about namespace at this point.
package org.apache.excalibur.meta;
/**
* The assembly of object instances of a components
* declared dependencies on other components, as well as dependency on a
* Logger, Configuration, Parameters and Context.
*/
interface MetaData
{
DependencyMetaData[] getDependencyData();
Logger getLogger();
Configuration getConfiguration();
Parameters getParameters();
Context getContext();
}
/**
* MetaInfo is an assembly of descriptors of a components declared
* dependencies on other components and on a Logger, Configuration,
* Parameters and Context, as well as a container for some
* human-readable information about the component.
*/
interface MetaInfo
{
ComponentDescriptor getDescription();
DependencyDescriptor[] getDependencies();
LoggerDescriptor getLogger();
ConfigurationDescriptor getConfiguration();
ParametersDescriptor getParameters();
ContextDescriptor getContext();
}
/**
* DependencyMetaData is the most complex part of the MetaData
* specification. It maps the dependencies a component declares on
* other components to a MetaInfo object.
*/
interface DependencyMetaData
{
MetaInfo[] getDependencies();
MetaInfo getDependency( String role );
}
/**
* A descriptor provides a piece of MetaInfo about a component.
*/
interface Descriptor
{
/**
* the common Descriptors (which extend this interface
* provide stronger typed access to Descriptor attributes.
* This method is here to allow for easier extension of
* the MetaInfo.
*
* @returns the requested attribute, or null if the attribute
* does not exist
*/
Object getAttribute( String key );
Object getAttribute( String key, Object defaultValue );
/**
* Check whether the descriptor provides this attribute.
*
* @returns true if it does, false if it doesn't
*/
boolean containsAttribute( String key );
}
/**
* provides valuable information to assembler and end user about a
* component.
*/
interface ComponentDescriptor extends Descriptor
{
String getName();
Version getVersion();
String getDescription();
String getDefaultRoleName();
}
/**
* Provide information about a component-to-component dependency
*/
interface DependencyDescriptor extends Descriptor
{
String getRole();
Version getVersion();
boolean isOptional();
boolean isRequired();
/* maybe...
DependencyDescriptor getAlternative();
boolean isAlternative( DependencyDescriptor descriptor );
boolean betterAlternativeTo( DependencyDescriptor descriptor );
*/
}
interface ContextDescriptor extends Descriptor
{
ContextEntryDescriptor[] getEntries();
ContextEntryDescriptor getEntry( String key );
String getType();
}
interface LoggerDescriptor extends Descriptor
{ /* you get the picture now */ }
interface ConfigurationDescriptor extends Descriptor
{ /* this one, I dunno how to handle :/ */ }
interface ParametersDescriptor extends Descriptor
{ /* you get the picture now */ }
Wrapping up
-----------
Basically I think it is a good idea we hammer out some definitions,
interfaces and contracts now. Part of why the discussion led to deadlock
before is that it focussed on implementations, where it isn't that much
of a problem if the implementation is container specific, as long as the
container accepts any component with complete MetaData and MetaInfo.
well?
best regards,
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Metadata and Metainfo model
Posted by Leo Simons <le...@apache.org>.
On Fri, 2002-07-05 at 09:31, Peter Donald wrote:
> At 09:25 AM 7/5/2002 +0200, you wrote:
> >okay. Would suggest provides() then
> >
> >ie SomeService 1.3.4 provide()s 1.3, but SomeService 1.3 doesn't
> >provide() 1.3.4
>
> Bad semantics - it doesn't provide. Maybe satisfies?
probably better.
> BTW matches() is common method name through JDK for similar which is why it
> was adopted.
in that case -- nevermind. It is not that important: primary users are
container writers, who should be smart enough to figure that out =)
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Metadata and Metainfo model
Posted by Peter Donald <pe...@apache.org>.
At 09:25 AM 7/5/2002 +0200, you wrote:
>okay. Would suggest provides() then
>
>ie SomeService 1.3.4 provide()s 1.3, but SomeService 1.3 doesn't
>provide() 1.3.4
Bad semantics - it doesn't provide. Maybe satisfies?
BTW matches() is common method name through JDK for similar which is why it
was adopted.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Metadata and Metainfo model
Posted by Leo Simons <le...@apache.org>.
okay. Would suggest provides() then
ie SomeService 1.3.4 provide()s 1.3, but SomeService 1.3 doesn't
provide() 1.3.4
- Leo
On Fri, 2002-07-05 at 09:12, Peter Donald wrote:
> At 09:08 AM 7/5/2002 +0200, you wrote:
> > > interface ServiceDesignator
> > > {
> > > Version getVersion();
> > > String getClassname();
> > > boolean matches( ServiceDesignator service );
> > > }
> >
> >okay. "matches()" is stupid though -- there's equals() to do just that.
> >Right?
>
> Matches is not the same as equals(). Matches allows you to have slightly
> different version services (as long as they follow certain rules). ie 1.3.4
> matches 1.3 but the reverse is not true.
>
> Cheers,
>
> Peter Donald
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "Faced with the choice between changing one's mind,
> and proving that there is no need to do so - almost
> everyone gets busy on the proof."
> - John Kenneth Galbraith
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> --
> 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: Component Metadata and Metainfo model
Posted by Peter Donald <pe...@apache.org>.
At 09:08 AM 7/5/2002 +0200, you wrote:
> > interface ServiceDesignator
> > {
> > Version getVersion();
> > String getClassname();
> > boolean matches( ServiceDesignator service );
> > }
>
>okay. "matches()" is stupid though -- there's equals() to do just that.
>Right?
Matches is not the same as equals(). Matches allows you to have slightly
different version services (as long as they follow certain rules). ie 1.3.4
matches 1.3 but the reverse is not true.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Metadata and Metainfo model
Posted by Stephen McConnell <mc...@osm.net>.
Leo Simons wrote:
>summary of below: agree, one clarification requested.
>
>- Leo
>
>
>
>>>Suggested interfaces
>>>--------------------
>>>This builds upon the current avalon containerkit package. Please don't
>>>worry too much about namespace at this point.
>>>
>>>package org.apache.excalibur.meta;
>>>
>>>/**
>>>* The assembly of object instances of a components
>>>* declared dependencies on other components, as well as dependency on a
>>>* Logger, Configuration, Parameters and Context.
>>>*/
>>>interface MetaData
>>>{
>>> DependencyMetaData[] getDependencyData();
>>> Logger getLogger();
>>> Configuration getConfiguration();
>>> Parameters getParameters();
>>> Context getContext();
>>>}
>>>
>>>
>>>
>>I think we need to add the following operation:
>>
>> MetaInfo getInfo();
>>
>>I.e. the association of a MetaData instance to its MetaInfo type or am I missing something?
>>
>>
>
>gotcha.
>
>
>
>>>interface MetaInfo
>>>{
>>> ComponentDescriptor getDescription();
>>> DependencyDescriptor[] getDependencies();
>>> LoggerDescriptor getLogger();
>>> ConfigurationDescriptor getConfiguration();
>>> ParametersDescriptor getParameters();
>>> ContextDescriptor getContext();
>>>}
>>>
>>>
>>>
>>Needs to include an accessor to the services descriptors provided by the
>>component type.
>>
>>
>
>gotcha
>
>
>
>>>/**
>>>* DependencyMetaData is the most complex part of the MetaData
>>>* specification. It maps the dependencies a component declares on
>>>* other components to a MetaInfo object.
>>>*/
>>>interface DependencyMetaData
>>>{
>>> MetaInfo[] getDependencies();
>>> MetaInfo getDependency( String role );
>>>}
>>>
>>>
>>>
>>Dependency meta data should be declaring the associations of providers
>>relative to a supplied role. I.e. you nedd to replace MetaInfo with
>>MetaData in the above interface.
>>
>>
>
>gotcha
>
>
>
>>>/**
>>>* provides valuable information to assembler and end user about a
>>>* component.
>>>*/
>>>interface ComponentDescriptor extends Descriptor
>>>{
>>> String getName();
>>> Version getVersion();
>>> String getDescription();
>>> String getDefaultRoleName();
>>>}
>>>
>>>
>>>
>>I think the operation "String getDefaultRoleName();" is unclear.
>>
>>
>
>I think so too. I figured it sounded just a little better than
>"getImplementationKey()".
>
>
>
>>The corresponding method in the containerkit class isn't any
>>better "String getImplemetationKey()". The problem is that value
>>returned from this operation is a key used by a container to access
>>the implementation class (the default value being the classname). This
>>implies that a container must provide a mapping from the key to a
>>component resolver/factory if the value is a key - however - a generic
>>container cannot know if the value is a key or a classname. Secondly -
>>the absence of an interface defining a factory/resolver means that it
>>will not be possible for a generic container to instantiate/resolve a
>>component instance.
>>
>>So you would have
>>
>>interface ComponentDescriptor extends Descriptor
>>{
>> // ...
>> ResolverDescriptor getResolver();
>> // ...
>>}
>>
>>
Exactly.
>>>/**
>>>* Provide information about a component-to-component dependency
>>>*/
>>>interface DependencyDescriptor extends Descriptor
>>>{
>>> String getRole();
>>> Version getVersion();
>>>
>>> boolean isOptional();
>>> boolean isRequired();
>>> /* maybe...
>>> DependencyDescriptor getAlternative();
>>> boolean isAlternative( DependencyDescriptor descriptor );
>>> boolean betterAlternativeTo( DependencyDescriptor descriptor );
>>> */
>>>}
>>>
>>>
>>>
>>Not favorable to the addition of alternatives (too much to do already
>>with basic dependecies and the notion of optional depedencies) - less is
>>better. Also, the above interface is missing the defintion of the
>>service interface. Actually, the containerkit model of the seperation
>>of the version and interface type into a seperate ServiceDesignator
>>works well.
>>
>>I.e.
>>
>>
>> interface DependencyDescriptor extends Descriptor
>> {
>> String getRole();
>> ServiceDesignator getService();
>> boolean isOptional();
>> boolean isRequired();
>> }
>>
>> interface ServiceDesignator
>> {
>> Version getVersion();
>> String getClassname();
>> boolean matches( ServiceDesignator service );
>> }
>>
>>
>
>okay. "matches()" is stupid though -- there's equals() to do just that.
>Right?
>
>
>
Nope - like Pete said - Version 2 matches version 2.1.
I use this sort of thing a lot as a result of version interfaces linked
to standard business objects.
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: Component Metadata and Metainfo model
Posted by Leo Simons <le...@apache.org>.
summary of below: agree, one clarification requested.
- Leo
> >Suggested interfaces
> >--------------------
> >This builds upon the current avalon containerkit package. Please don't
> >worry too much about namespace at this point.
> >
> >package org.apache.excalibur.meta;
> >
> >/**
> > * The assembly of object instances of a components
> > * declared dependencies on other components, as well as dependency on a
> > * Logger, Configuration, Parameters and Context.
> > */
> >interface MetaData
> >{
> > DependencyMetaData[] getDependencyData();
> > Logger getLogger();
> > Configuration getConfiguration();
> > Parameters getParameters();
> > Context getContext();
> >}
> >
>
> I think we need to add the following operation:
>
> MetaInfo getInfo();
>
> I.e. the association of a MetaData instance to its MetaInfo type or am I missing something?
gotcha.
> >interface MetaInfo
> >{
> > ComponentDescriptor getDescription();
> > DependencyDescriptor[] getDependencies();
> > LoggerDescriptor getLogger();
> > ConfigurationDescriptor getConfiguration();
> > ParametersDescriptor getParameters();
> > ContextDescriptor getContext();
> >}
> >
>
> Needs to include an accessor to the services descriptors provided by the
> component type.
gotcha
> >/**
> > * DependencyMetaData is the most complex part of the MetaData
> > * specification. It maps the dependencies a component declares on
> > * other components to a MetaInfo object.
> > */
> >interface DependencyMetaData
> >{
> > MetaInfo[] getDependencies();
> > MetaInfo getDependency( String role );
> >}
> >
>
> Dependency meta data should be declaring the associations of providers
> relative to a supplied role. I.e. you nedd to replace MetaInfo with
> MetaData in the above interface.
gotcha
> >/**
> > * provides valuable information to assembler and end user about a
> > * component.
> > */
> >interface ComponentDescriptor extends Descriptor
> >{
> > String getName();
> > Version getVersion();
> > String getDescription();
> > String getDefaultRoleName();
> >}
> >
>
> I think the operation "String getDefaultRoleName();" is unclear.
I think so too. I figured it sounded just a little better than
"getImplementationKey()".
> The corresponding method in the containerkit class isn't any better
"String getImplemetationKey()". The problem is that value returned from
> this operation is a key used by a container to access the
implementation class (the default value being the classname). This
implies that a container must provide a mapping from the key to a
component resolver/factory if the value is a key - however - a generic
container cannot know if the value is a key or a classname. Secondly -
the absence of an interface defining a factory/resolver means that it
will not be possible for a generic container to instantiate/resolve a
component instance.
So you would have
interface ComponentDescriptor extends Descriptor
{
// ...
ResolverDescriptor getResolver();
// ...
}
> >/**
> > * Provide information about a component-to-component dependency
> > */
> >interface DependencyDescriptor extends Descriptor
> >{
> > String getRole();
> > Version getVersion();
> >
> > boolean isOptional();
> > boolean isRequired();
> > /* maybe...
> > DependencyDescriptor getAlternative();
> > boolean isAlternative( DependencyDescriptor descriptor );
> > boolean betterAlternativeTo( DependencyDescriptor descriptor );
> > */
> >}
> >
>
> Not favorable to the addition of alternatives (too much to do already
> with basic dependecies and the notion of optional depedencies) - less is
> better. Also, the above interface is missing the defintion of the
> service interface. Actually, the containerkit model of the seperation
> of the version and interface type into a seperate ServiceDesignator
> works well.
>
> I.e.
>
>
> interface DependencyDescriptor extends Descriptor
> {
> String getRole();
> ServiceDesignator getService();
> boolean isOptional();
> boolean isRequired();
> }
>
> interface ServiceDesignator
> {
> Version getVersion();
> String getClassname();
> boolean matches( ServiceDesignator service );
> }
okay. "matches()" is stupid though -- there's equals() to do just that.
Right?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Metadata and Metainfo model
Posted by Stephen McConnell <mc...@osm.net>.
Leo Simons wrote:
>all,
>
>we have determined there is a need for a common object model to
>represent metadata and metainfo for avalon components. This to allow for
>portability of said components across containers.
>
>This object model has to be formalized in a way quite similar to the
>framework lifecycle, hence it is currently partially in the same
>excalibur module: containerkit.
>
>Definitions
>-----------
>metadata - basic definition: MetaData is everything that has to be
>provided to a component by its container in order for the component to
>function properly.
>
>metadata - avalon definition: MetaData is the assembly of object
>instances of a components declared dependencies on other components, as
>well as dependency on a Logger, Configuration, Parameters and Context.
>
>metainfo - basic definition: MetaInfo is a complete description of
>MetaData. Complete MetaInfo can be used to generate complete MetaData.
>
>metainfo - avalon definition: MetaInfo is an assembly of descriptors of
>a components declared dependencies on other components and on a Logger,
>Configuration, Parameters and Context, as well as a container for some
>human-readable information about the component.
>
Yep - I agree with the scope and defintions described above.
>
>note: metadata and metainfo is partly provided by java itself, primarily
>in the form of the Class method and related (ie Method). Additional
>standard metadata and info is provided in the form of descriptors first
>introduced with JavaBeans, where the information provided by Class is
>expended by providing an optional <<classname>>BeanInfo class. Other
>specifications like JMX expand on this (JMX has the option of providing
>a class extending MBeanInfo).
>
>current situation
>-----------------
>ECM is a bit of a mess wrt to metadata/metainfo. Phoenix allows
>specification of metadata through <<classname>>.xinfo files, as well as
>through xml configuration. Merlin partially allows the same
>configuration, and does some smart automatic determinition where an
>xinfo file is not provided.
>
Minor correction - Merlin does smart automatic determinition of the
mapping of consumer and provider components without the requirment for
explicit assembly directives.
>
>Suggested interfaces
>--------------------
>This builds upon the current avalon containerkit package. Please don't
>worry too much about namespace at this point.
>
>package org.apache.excalibur.meta;
>
>/**
> * The assembly of object instances of a components
> * declared dependencies on other components, as well as dependency on a
> * Logger, Configuration, Parameters and Context.
> */
>interface MetaData
>{
> DependencyMetaData[] getDependencyData();
> Logger getLogger();
> Configuration getConfiguration();
> Parameters getParameters();
> Context getContext();
>}
>
I think we need to add the following operation:
MetaInfo getInfo();
I.e. the association of a MetaData instance to its MetaInfo type or am I missing something?
>
>
>/**
> * MetaInfo is an assembly of descriptors of a components declared
> * dependencies on other components and on a Logger, Configuration,
> * Parameters and Context, as well as a container for some
> * human-readable information about the component.
> */
>interface MetaInfo
>{
> ComponentDescriptor getDescription();
> DependencyDescriptor[] getDependencies();
> LoggerDescriptor getLogger();
> ConfigurationDescriptor getConfiguration();
> ParametersDescriptor getParameters();
> ContextDescriptor getContext();
>}
>
Needs to include an accessor to the services descriptors provided by the
component type.
interface MetaInfo
{
ComponentDescriptor getDescription();
ServiceDescriptor[] getServices(); //**
DependencyDescriptor[] getDependencies();
LoggerDescriptor getLogger();
ConfigurationDescriptor getConfiguration();
ParametersDescriptor getParameters();
ContextDescriptor getContext();
}
interface ServiceDescriptor
extends FeatureDescriptor, ServiceDesignator
{
}
>
>
>/**
> * DependencyMetaData is the most complex part of the MetaData
> * specification. It maps the dependencies a component declares on
> * other components to a MetaInfo object.
> */
>interface DependencyMetaData
>{
> MetaInfo[] getDependencies();
> MetaInfo getDependency( String role );
>}
>
Dependency meta data should be declaring the associations of providers
relative to a supplied role. I.e. you nedd to replace MetaInfo with
MetaData in the above interface.
interface DependencyMetaData
{
MetaData[] getDependencies();
MetaData getDependency( String role );
}
>
>
>/**
> * A descriptor provides a piece of MetaInfo about a component.
> */
>interface Descriptor
>{
> /**
> * the common Descriptors (which extend this interface
> * provide stronger typed access to Descriptor attributes.
> * This method is here to allow for easier extension of
> * the MetaInfo.
> *
> * @returns the requested attribute, or null if the attribute
> * does not exist
> */
> Object getAttribute( String key );
> Object getAttribute( String key, Object defaultValue );
>
> /**
> * Check whether the descriptor provides this attribute.
> *
> * @returns true if it does, false if it doesn't
> */
> boolean containsAttribute( String key );
>}
>
>/**
> * provides valuable information to assembler and end user about a
> * component.
> */
>interface ComponentDescriptor extends Descriptor
>{
> String getName();
> Version getVersion();
> String getDescription();
> String getDefaultRoleName();
>}
>
I think the operation "String getDefaultRoleName();" is unclear. The corresponding method in the containerkit class isn't any better "String getImplemetationKey()". The problem is that value returned from this operation is a key used by a container to access the implementation class (the default value being the classname). This implies that a container must provide a mapping from the key to a component resolver/factory if the value is a key - however - a generic container cannot know if the value is a key or a classname. Secondly - the absence of an interface defining a factory/resolver means that it will not be possible for a generic container to instantiate/resolve a component instance.
IMO it would be better to be explicit about this in the metainfo model by declaring a resolver/factory classname that a key is evaluated against, and, specification of a resolver/factory interface that a generic container can use.
>
>
>/**
> * Provide information about a component-to-component dependency
> */
>interface DependencyDescriptor extends Descriptor
>{
> String getRole();
> Version getVersion();
>
> boolean isOptional();
> boolean isRequired();
> /* maybe...
> DependencyDescriptor getAlternative();
> boolean isAlternative( DependencyDescriptor descriptor );
> boolean betterAlternativeTo( DependencyDescriptor descriptor );
> */
>}
>
Not favorable to the addition of alternatives (too much to do already
with basic dependecies and the notion of optional depedencies) - less is
better. Also, the above interface is missing the defintion of the
service interface. Actually, the containerkit model of the seperation
of the version and interface type into a seperate ServiceDesignator
works well.
I.e.
interface DependencyDescriptor extends Descriptor
{
String getRole();
ServiceDesignator getService();
boolean isOptional();
boolean isRequired();
}
interface ServiceDesignator
{
Version getVersion();
String getClassname();
boolean matches( ServiceDesignator service );
}
>
>
>interface ContextDescriptor extends Descriptor
>{
> ContextEntryDescriptor[] getEntries();
> ContextEntryDescriptor getEntry( String key );
> String getType();
>}
>
>interface LoggerDescriptor extends Descriptor
>{ /* you get the picture now */ }
>
>interface ConfigurationDescriptor extends Descriptor
>{ /* this one, I dunno how to handle :/ */ }
>
I'm happy with the existance of the interface as this will allow
seperation of the concern for future configuration constraints from the
overall object model.
>
>
>interface ParametersDescriptor extends Descriptor
>{ /* you get the picture now */ }
>
>
>
>Wrapping up
>-----------
>Basically I think it is a good idea we hammer out some definitions,
>interfaces and contracts now. Part of why the discussion led to deadlock
>before is that it focussed on implementations, where it isn't that much
>of a problem if the implementation is container specific, as long as the
>container accepts any component with complete MetaData and MetaInfo.
>
>well?
>
This will certainly move things towards a more open framework - I like it.
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: Component Metadata and Metainfo model
Posted by Peter Donald <pe...@apache.org>.
At 10:27 AM 7/5/2002 +0200, you wrote:
>On Fri, 2002-07-05 at 09:29, Peter Donald wrote:
> > At 09:17 AM 7/5/2002 +0200, you wrote:
> > > > Never going to use an interface again for this. If you remember
> back about
> > > > 1 1/2 years ago we separated out interface and implementations for the
> > > meta
> > > > classes. It sucked hugely.
> > >
> > >Can't say that I do...could you provide a keyword or archive link?
> >
> > Nope. Have a look through phoenixs CVS history it should be there.
> > Previously I tried to write a generic container infrastructure but failed
> > miserably due to overspecification of everything. The results of this are
> > scattered through history of jakarta-avalon and
> > jakarta-avalon-excalibur/all CVSes under the "container" package.
>
>rings a bell. What was it again, camelot 'n friends?
camelot and atlantis were later evolutions of it.
>At that point, I think we removed it because the only 'real' container
>we had was phoenix (ECM wasn't really viewed as such) so it made no
>sense to separate any of it out.
I removed it because it sucked ;) It was too over specified and required
too much architectural investment to be useful outside of a very small
range of situations.
>Now, we have quite a few containers (and everyone now has an idea of
>what it is and does) and some more experience. I'd say the situation
>thus has improved to a point where more people get what we're doing, and
>on the other hand we're off worse because there is no portability.
>
>Hence trying once again, no?
Well I only started containerkit so I can share stuff between Cocoon and
myrmidon. Interoperability between those two (and Phoenix if possible) is
still main objective for me.
> > Your definitions differ from mine then. Metainfo is meta information about
> > type. (MOF Level 0 MetaData). It has 0 information about profile prototype
> > or anything similar.
>
>MOF?
Meta-Object framework maybe ?? One of OMGs numerous specifications.
> > MetaData is the component profile.
> >
> > Entry is the runtime information about component. ie Actual Logger,
> > Context, instance (or pool), dependency instance references etc.
> >
> > My model does not say anything about component profile prototype. I was
> not
> > going to address it as I wanted to see the outcome of work that Peter is
> > doing on phoenix and Stephen is doing on Merlin.
> >
> > The model also does not offer a COnfiguration or Parameters Schema yet
> > (again I am waiting to see experimentation on Phoenix).
>
>ah. These definitions aren't very clear from looking at the current
>containerkit :/
>
>I take it I should look at kernel.ComponentEntry....that's pretty devoid
>of any explanation or contract atm...I take it the idea is to expand on
>it once we know a bit more?
No - it will be deleted once the rest of containerkit is validated. I am
just using it as testing framework to see what works and what doesn't. It
may grow into something else but not its main objective.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Metadata and Metainfo model
Posted by Stephen McConnell <mc...@osm.net>.
Leo Simons wrote:
>>>anyways, I sort-of get the direction headed and I'll start with throwing
>>>in a bit of (javadoc) documentation in the general direction of
>>>containerkit.
>>>
>>>
>>In the meantime I'm going to play around with a fork of containerkit
>>(metainfo, metadata, infobuilder and verifier) so I can actually get
>>into classes and do what I need to do.
>>
>>
>
>where are ya gonna stuff it?
>
Excalibur / Assembly (a.k.a Merlin 2)
package org.excalibure.meta.*
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: Component Metadata and Metainfo model
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
>>>anyways, I sort-of get the direction headed and I'll start with throwing
>>>in a bit of (javadoc) documentation in the general direction of
>>>containerkit.
>>
>>In the meantime I'm going to play around with a fork of containerkit
>>(metainfo, metadata, infobuilder and verifier) so I can actually get
>>into classes and do what I need to do.
>
>
> where are ya gonna stuff it?
>
> We should define a sandbox for all of avalon. The current
> excalibur/all/scratchpad doesn't really cut it for me. Do you think many
> will scream at YAAC (Yet Another Avalon CVS)? I'd like one...
Ever heard of branching? ;-P
IMHO it's the most correct thing to use in this case.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Metadata and Metainfo model
Posted by Leo Simons <le...@apache.org>.
> >MOF?
> >
>
> Meta Object Facilty - an OMG specification that is basically the core
eeeek! I *do* not want to go through all that stuff again...it took
quite some effort to forget 8)
> >>MetaData is the component profile.
> >>
> >>Entry is the runtime information about component. ie Actual Logger,
> >>Context, instance (or pool), dependency instance references etc.
> >>
> >>My model does not say anything about component profile prototype. I was not
> >>going to address it as I wanted to see the outcome of work that Peter is
> >>doing on phoenix and Stephen is doing on Merlin.
> >>
> >>The model also does not offer a COnfiguration or Parameters Schema yet
> >>(again I am waiting to see experimentation on Phoenix).
> >>
> >>
> >
> >ah. These definitions aren't very clear from looking at the current
> >containerkit :/
> >
> >
>
> Naming, naming naming.
> It matters.
> :-)
a lot.
> >anyways, I sort-of get the direction headed and I'll start with throwing
> >in a bit of (javadoc) documentation in the general direction of
> >containerkit.
>
> In the meantime I'm going to play around with a fork of containerkit
> (metainfo, metadata, infobuilder and verifier) so I can actually get
> into classes and do what I need to do.
where are ya gonna stuff it?
We should define a sandbox for all of avalon. The current
excalibur/all/scratchpad doesn't really cut it for me. Do you think many
will scream at YAAC (Yet Another Avalon CVS)? I'd like one...
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Metadata and Metainfo model
Posted by Stephen McConnell <mc...@osm.net>.
Leo Simons wrote:
>On Fri, 2002-07-05 at 09:29, Peter Donald wrote:
>
>
>>At 09:17 AM 7/5/2002 +0200, you wrote:
>>
>>
>>>>Never going to use an interface again for this. If you remember back about
>>>>1 1/2 years ago we separated out interface and implementations for the
>>>>
>>>>
>>>meta
>>>
>>>
>>>>classes. It sucked hugely.
>>>>
>>>>
>>>Can't say that I do...could you provide a keyword or archive link?
>>>
>>>
>>Nope. Have a look through phoenixs CVS history it should be there.
>>Previously I tried to write a generic container infrastructure but failed
>>miserably due to overspecification of everything. The results of this are
>>scattered through history of jakarta-avalon and
>>jakarta-avalon-excalibur/all CVSes under the "container" package.
>>
>>
>
>rings a bell. What was it again, camelot 'n friends?
>
>At that point, I think we removed it because the only 'real' container
>we had was phoenix (ECM wasn't really viewed as such) so it made no
>sense to separate any of it out.
>
>Now, we have quite a few containers (and everyone now has an idea of
>what it is and does) and some more experience. I'd say the situation
>thus has improved to a point where more people get what we're doing, and
>on the other hand we're off worse because there is no portability.
>
>Hence trying once again, no?
>
>
>
>> > >{
>>
>>
>>>>> DependencyMetaData[] getDependencyData();
>>>>> Logger getLogger();
>>>>>
>>>>>
>>>>-1
>>>>This should go into component entry not metadata as it is tied to a
>>>>particular instance, not a profile.
>>>>
>>>>
>>>in my definitions of metadata and metainfo, metadata is indeed tied to a
>>>particular instance, or at least to a group of functionally equivalent
>>>instances (ie a pool). It is more or less the same as a component entry.
>>>
>>>The metainfo is the profile.
>>>
>>>
>>Your definitions differ from mine then. Metainfo is meta information about
>>type. (MOF Level 0 MetaData). It has 0 information about profile prototype
>>or anything similar.
>>
>>
>
>MOF?
>
Meta Object Facilty - an OMG specification that is basically the core
spec of the Java Meta stuff (at the least the Java stuff can be
considered as a mapping from Java to the MOF). Great reading - but take
a could of Asprin first.
>
>
>
>>MetaData is the component profile.
>>
>>Entry is the runtime information about component. ie Actual Logger,
>>Context, instance (or pool), dependency instance references etc.
>>
>>My model does not say anything about component profile prototype. I was not
>>going to address it as I wanted to see the outcome of work that Peter is
>>doing on phoenix and Stephen is doing on Merlin.
>>
>>The model also does not offer a COnfiguration or Parameters Schema yet
>>(again I am waiting to see experimentation on Phoenix).
>>
>>
>
>ah. These definitions aren't very clear from looking at the current
>containerkit :/
>
>
Naming, naming naming.
It matters.
:-)
>I take it I should look at kernel.ComponentEntry....that's pretty devoid
>of any explanation or contract atm...I take it the idea is to expand on
>it once we know a bit more?
>
Its an container internal reosurce - should not effect the MetaInfo,
MetaModel discussion.
>
>anyways, I sort-of get the direction headed and I'll start with throwing
>in a bit of (javadoc) documentation in the general direction of
>containerkit.
>
>
In the meantime I'm going to play around with a fork of containerkit
(metainfo, metadata, infobuilder and verifier) so I can actually get
into classes and do what I need to do.
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: Component Metadata and Metainfo model
Posted by Leo Simons <le...@apache.org>.
On Fri, 2002-07-05 at 09:29, Peter Donald wrote:
> At 09:17 AM 7/5/2002 +0200, you wrote:
> > > Never going to use an interface again for this. If you remember back about
> > > 1 1/2 years ago we separated out interface and implementations for the
> > meta
> > > classes. It sucked hugely.
> >
> >Can't say that I do...could you provide a keyword or archive link?
>
> Nope. Have a look through phoenixs CVS history it should be there.
> Previously I tried to write a generic container infrastructure but failed
> miserably due to overspecification of everything. The results of this are
> scattered through history of jakarta-avalon and
> jakarta-avalon-excalibur/all CVSes under the "container" package.
rings a bell. What was it again, camelot 'n friends?
At that point, I think we removed it because the only 'real' container
we had was phoenix (ECM wasn't really viewed as such) so it made no
sense to separate any of it out.
Now, we have quite a few containers (and everyone now has an idea of
what it is and does) and some more experience. I'd say the situation
thus has improved to a point where more people get what we're doing, and
on the other hand we're off worse because there is no portability.
Hence trying once again, no?
> > >{
> > > > DependencyMetaData[] getDependencyData();
> > > > Logger getLogger();
> > >
> > > -1
> > > This should go into component entry not metadata as it is tied to a
> > > particular instance, not a profile.
> >
> >in my definitions of metadata and metainfo, metadata is indeed tied to a
> >particular instance, or at least to a group of functionally equivalent
> >instances (ie a pool). It is more or less the same as a component entry.
> >
> >The metainfo is the profile.
>
> Your definitions differ from mine then. Metainfo is meta information about
> type. (MOF Level 0 MetaData). It has 0 information about profile prototype
> or anything similar.
MOF?
> MetaData is the component profile.
>
> Entry is the runtime information about component. ie Actual Logger,
> Context, instance (or pool), dependency instance references etc.
>
> My model does not say anything about component profile prototype. I was not
> going to address it as I wanted to see the outcome of work that Peter is
> doing on phoenix and Stephen is doing on Merlin.
>
> The model also does not offer a COnfiguration or Parameters Schema yet
> (again I am waiting to see experimentation on Phoenix).
ah. These definitions aren't very clear from looking at the current
containerkit :/
I take it I should look at kernel.ComponentEntry....that's pretty devoid
of any explanation or contract atm...I take it the idea is to expand on
it once we know a bit more?
anyways, I sort-of get the direction headed and I'll start with throwing
in a bit of (javadoc) documentation in the general direction of
containerkit.
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Metadata and Metainfo model
Posted by Peter Donald <pe...@apache.org>.
At 09:17 AM 7/5/2002 +0200, you wrote:
> > Never going to use an interface again for this. If you remember back about
> > 1 1/2 years ago we separated out interface and implementations for the
> meta
> > classes. It sucked hugely.
>
>Can't say that I do...could you provide a keyword or archive link?
Nope. Have a look through phoenixs CVS history it should be there.
Previously I tried to write a generic container infrastructure but failed
miserably due to overspecification of everything. The results of this are
scattered through history of jakarta-avalon and
jakarta-avalon-excalibur/all CVSes under the "container" package.
> >{
> > > DependencyMetaData[] getDependencyData();
> > > Logger getLogger();
> >
> > -1
> > This should go into component entry not metadata as it is tied to a
> > particular instance, not a profile.
>
>in my definitions of metadata and metainfo, metadata is indeed tied to a
>particular instance, or at least to a group of functionally equivalent
>instances (ie a pool). It is more or less the same as a component entry.
>
>The metainfo is the profile.
Your definitions differ from mine then. Metainfo is meta information about
type. (MOF Level 0 MetaData). It has 0 information about profile prototype
or anything similar.
MetaData is the component profile.
Entry is the runtime information about component. ie Actual Logger,
Context, instance (or pool), dependency instance references etc.
My model does not say anything about component profile prototype. I was not
going to address it as I wanted to see the outcome of work that Peter is
doing on phoenix and Stephen is doing on Merlin.
The model also does not offer a COnfiguration or Parameters Schema yet
(again I am waiting to see experimentation on Phoenix).
> > >interface ComponentDescriptor extends Descriptor
> > >{
> > > String getName();
> > > Version getVersion();
> > > String getDescription();
> > > String getDefaultRoleName();
> >
> > -1 only makes sense in some containers. Thus it should be an attribute.
>
>You mean the descriptor as a whole or the getDefaultRoleName()?
default role name
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Metadata and Metainfo model
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
>>Just a note - I hate the MetaThis, MetaThat frequence. It's really
>>confusing for users.
>>What I'm doing locally is:
>>
>> Type <--- was ComponentInfo
>> Profile <-- was ComponentMetaData
>> Association <-- was DependecyMetaData
>>
>>Clarity in naming is important.
>
>
> I like ;)
Yeah, IMNSHO something between these lines is really important.
:-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Metadata and Metainfo model
Posted by Leo Simons <le...@apache.org>.
> Just a note - I hate the MetaThis, MetaThat frequence. It's really
> confusing for users.
> What I'm doing locally is:
>
> Type <--- was ComponentInfo
> Profile <-- was ComponentMetaData
> Association <-- was DependecyMetaData
>
> Clarity in naming is important.
I like ;)
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Metadata and Metainfo model
Posted by Stephen McConnell <mc...@osm.net>.
Leo Simons wrote:
>>>Never going to use an interface again for this. If you remember back
>>>about 1 1/2 years ago we separated out interface and implementations for
>>>the meta classes. It sucked hugely.
>>>
>>>
>>I don't know if it sucked or it spit :-) , but what is the need of
>>having an interface versus implementation?
>>Will there be many implementations, one for each container? Why is it
>>needed?
>>
>>
>
>It seems there may indeed be multiple implementations. FA, Stephen has
>already extended metadata (think it is called "profile" or something).
>
>
I've extended ComponentMetaData (to Profile) and ComponetInfo (to Type).
Having interfaces around these two is desirable - in fact I'm playing
around with this at the moment. Under the containerkit varient the
ComponentMetaData requires the client to supply fully prepared
DependecyMetaData instances - and that a really painfull constraint.
Life becomes dramtically easier if I can incrementally at dependecy
meta data as a I navigate containers. I'm not saying this justifies an
interface - but it cetainly makes life easier if I use an alternative
implemetation that I can change to meet requirements.
Just a note - I hate the MetaThis, MetaThat frequence. It's really
confusing for users.
What I'm doing locally is:
Type <--- was ComponentInfo
Profile <-- was ComponentMetaData
Association <-- was DependecyMetaData
Clarity in naming is important.
>The main reason I chose to use interfaces in the setup is that
>interfaces (at least at avalon) imply contracts rather than
>implementations, and I feel what we should be discussing is contracts
>instead of implementation details.
>
>
>
>>Since this is just a "structure" (no "real" methods), it seems that
>>using interfaces is not needed.
>>
>>
>
>yup.
>
>
I agree with exception on the ComponentInfo class and ComponentMetaData
class. The need to specialize ComponentInfo may dissapear but I also
have in the back of my mind the meta model extensions OSM has produced
for collaborative components using DPML (Digital Product Modelling
Language). As far as ComponentMetaData in concerned - this is a issue I
have with the constructor constraints - final and imuutable if fine for
Phoenix - it suck for Merlin (too static).
>
>
>>Yes, why are they here?
>>What would they be used for?
>>I don't understand.
>>
>>
>
>simple enough: to pass to the component. You can see this as a
>formalization of phoenix its ApplicationEntry (if that still exists....)
>
>
>
>>I think we should standardize on some common stuff to describe
>>components, ie
>>- version
>>- role
>>- description
>>
>>Where is doesn't make sense, a default version or description is used.
>>
>>
>
>yup. There is some stuff in containerkit already to do this. Basically,
>there is
>
>- role
>- service description
> [version, classname, attributes]
>- attributes
>
>
>
>>>-1
>>>Selection criterion are context sensitive and can be relegated to a
>>>particular container implementation.
>>>
>>>
>>Selection cretarion are "context sensitive"? You mean that selection
>>is done depending on what you have to select?
>>
>>I don't think so, assembly semantics *has* to be the same if we want
>>things to work between containers.
>>
>>
>
>Nah, as soon as you start discussing "possible alternatives" the
>selection between different alternatives can be container specific (I
>*think* that's what he ment, anyway).
>
>
Just for reference - Merlin 2 enables service selection by user supplied
plug-ins which can be declared in the dependency attributes, or
alternatively, can be supplied at a container level applying to all
services of the type. Meta defined selection overrides container wide
selection overrides default selection.
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: Component Metadata and Metainfo model
Posted by Leo Simons <le...@apache.org>.
> > Never going to use an interface again for this. If you remember back
> > about 1 1/2 years ago we separated out interface and implementations for
> > the meta classes. It sucked hugely.
>
> I don't know if it sucked or it spit :-) , but what is the need of
> having an interface versus implementation?
> Will there be many implementations, one for each container? Why is it
> needed?
It seems there may indeed be multiple implementations. FA, Stephen has
already extended metadata (think it is called "profile" or something).
The main reason I chose to use interfaces in the setup is that
interfaces (at least at avalon) imply contracts rather than
implementations, and I feel what we should be discussing is contracts
instead of implementation details.
> Since this is just a "structure" (no "real" methods), it seems that
> using interfaces is not needed.
yup.
> Yes, why are they here?
> What would they be used for?
> I don't understand.
simple enough: to pass to the component. You can see this as a
formalization of phoenix its ApplicationEntry (if that still exists....)
> I think we should standardize on some common stuff to describe
> components, ie
> - version
> - role
> - description
>
> Where is doesn't make sense, a default version or description is used.
yup. There is some stuff in containerkit already to do this. Basically,
there is
- role
- service description
[version, classname, attributes]
- attributes
> > -1
> > Selection criterion are context sensitive and can be relegated to a
> > particular container implementation.
>
> Selection cretarion are "context sensitive"? You mean that selection
> is done depending on what you have to select?
>
> I don't think so, assembly semantics *has* to be the same if we want
> things to work between containers.
Nah, as soon as you start discussing "possible alternatives" the
selection between different alternatives can be container specific (I
*think* that's what he ment, anyway).
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Metadata and Metainfo model
Posted by Peter Donald <pe...@apache.org>.
At 08:38 AM 7/5/2002 +0200, you wrote:
>>>{
>>> String getName();
>>> Version getVersion();
>>> String getDescription();
>>> String getDefaultRoleName();
>>
>>-1 only makes sense in some containers. Thus it should be an attribute.
>
>I think we should standardize on some common stuff to describe components, ie
>- version
That I agree with.
>- role
If you changed this to "services I offer" then we already have that.
However indicating which is default is contain specific. To implement it we
could add an attribute to the component (saying service X is default) or
adding attribute to the default service indicating that the service is default.
>- description
Almost every feature can have a description so we should make this an
attribute.
>>>/**
>>> * Provide information about a component-to-component dependency
>>> */
>>>interface DependencyDescriptor extends Descriptor
>>>{
>>> String getRole();
>>> Version getVersion();
>>>
>>> boolean isOptional();
>>> boolean isRequired();
>>> /* maybe...
>>> DependencyDescriptor getAlternative();
>>> boolean isAlternative( DependencyDescriptor descriptor );
>>> boolean betterAlternativeTo( DependencyDescriptor descriptor );
>>> */
>>
>>-1
>>Selection criterion are context sensitive and can be relegated to a
>>particular container implementation.
>
>Selection cretarion are "context sensitive"? You mean that selection
>is done depending on what you have to select?
>
>I don't think so, assembly semantics *has* to be the same if we want
>things to work between containers.
Containers who auto assemble an application are likely to want to apply
different criteria during autoassembly. All the meta data is going to be
able to do is ask;
Will Provider Component A satisfy Dependency X of COnsumer Component B?
If multiple Provider Components satisfy dependency X, which should you select?
Do you select Provider P that is distributed, clustered, implements
failblah error recovery etc? Or do you select Provider Q which lightweight
and fast? What about Component R that cost $10 per usage but is highest
quality of lot?
These are questions that are answered by hueristics written by container
provider.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Metadata and Metainfo model
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> At 11:42 PM 7/4/2002 +0200, you wrote:
>
>> Suggested interfaces
>> --------------------
>> This builds upon the current avalon containerkit package. Please don't
>> worry too much about namespace at this point.
>>
>> package org.apache.excalibur.meta;
>>
>> /**
>> * The assembly of object instances of a components
>> * declared dependencies on other components, as well as dependency on a
>> * Logger, Configuration, Parameters and Context.
>> */
>> interface MetaData
>
>
> Never going to use an interface again for this. If you remember back
> about 1 1/2 years ago we separated out interface and implementations for
> the meta classes. It sucked hugely.
I don't know if it sucked or it spit :-) , but what is the need of
having an interface versus implementation?
Will there be many implementations, one for each container? Why is it
needed?
Since this is just a "structure" (no "real" methods), it seems that
using interfaces is not needed.
>> {
>> DependencyMetaData[] getDependencyData();
>> Logger getLogger();
>
>
> -1
> This should go into component entry not metadata as it is tied to a
> particular instance, not a profile.
>
>> Configuration getConfiguration();
>> Parameters getParameters();
>> Context getContext();
>
>
> -1
>
> Same reason as above.
Yes, why are they here?
What would they be used for?
I don't understand.
> /**
>
>> * provides valuable information to assembler and end user about a
>> * component.
>> */
>> interface ComponentDescriptor extends Descriptor
>> {
>> String getName();
>> Version getVersion();
>> String getDescription();
>> String getDefaultRoleName();
>
>
> -1 only makes sense in some containers. Thus it should be an attribute.
I think we should standardize on some common stuff to describe
components, ie
- version
- role
- description
Where is doesn't make sense, a default version or description is used.
>> /**
>> * Provide information about a component-to-component dependency
>> */
>> interface DependencyDescriptor extends Descriptor
>> {
>> String getRole();
>> Version getVersion();
>>
>> boolean isOptional();
>> boolean isRequired();
>> /* maybe...
>> DependencyDescriptor getAlternative();
>> boolean isAlternative( DependencyDescriptor descriptor );
>> boolean betterAlternativeTo( DependencyDescriptor descriptor );
>> */
>
>
> -1
> Selection criterion are context sensitive and can be relegated to a
> particular container implementation.
Selection cretarion are "context sensitive"? You mean that selection
is done depending on what you have to select?
I don't think so, assembly semantics *has* to be the same if we want
things to work between containers.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Metadata and Metainfo model
Posted by Leo Simons <le...@apache.org>.
On Fri, 2002-07-05 at 02:46, Peter Donald wrote:
> At 11:42 PM 7/4/2002 +0200, you wrote:
> >Suggested interfaces
> >--------------------
> >This builds upon the current avalon containerkit package. Please don't
> >worry too much about namespace at this point.
> >
> >package org.apache.excalibur.meta;
> >
> >/**
> > * The assembly of object instances of a components
> > * declared dependencies on other components, as well as dependency on a
> > * Logger, Configuration, Parameters and Context.
> > */
> >interface MetaData
>
> Never going to use an interface again for this. If you remember back about
> 1 1/2 years ago we separated out interface and implementations for the meta
> classes. It sucked hugely.
Can't say that I do...could you provide a keyword or archive link?
Regardless, Nicola is right that what we do here is mostly defining
"structs" so use of interfaces isn't really necessary. The reason they
*are* necessary atm is that there is apparantly a need for multiple
("specialized"/"container specific") implementations/extensions to the
model, and current discussions were focussing on implementations rather
than contracts. I'm perfectly fine with not having interfaces; they are
just the means I chose to try and define contracts.
> >{
> > DependencyMetaData[] getDependencyData();
> > Logger getLogger();
>
> -1
> This should go into component entry not metadata as it is tied to a
> particular instance, not a profile.
in my definitions of metadata and metainfo, metadata is indeed tied to a
particular instance, or at least to a group of functionally equivalent
instances (ie a pool). It is more or less the same as a component entry.
The metainfo is the profile.
> /**
> > * provides valuable information to assembler and end user about a
> > * component.
> > */
> >interface ComponentDescriptor extends Descriptor
> >{
> > String getName();
> > Version getVersion();
> > String getDescription();
> > String getDefaultRoleName();
>
> -1 only makes sense in some containers. Thus it should be an attribute.
You mean the descriptor as a whole or the getDefaultRoleName()?
> >interface DependencyDescriptor extends Descriptor
> >{
> > String getRole();
> > Version getVersion();
> >
> > boolean isOptional();
> > boolean isRequired();
> > /* maybe...
> > DependencyDescriptor getAlternative();
> > boolean isAlternative( DependencyDescriptor descriptor );
> > boolean betterAlternativeTo( DependencyDescriptor descriptor );
> > */
>
> -1
> Selection criterion are context sensitive and can be relegated to a
> particular container implementation.
I assume you refer to the bits between /* maybe... */, and I agree. It
was a bad idea.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Component Metadata and Metainfo model
Posted by Peter Donald <pe...@apache.org>.
At 08:59 AM 7/5/2002 +0200, you wrote:
> > From: Peter Donald [mailto:peter@apache.org]
> >
> > >{
> > > DependencyMetaData[] getDependencyData();
> > > Logger getLogger();
> >
> > -1
> > This should go into component entry not metadata as it is tied to a
> > particular instance, not a profile.
> >
> > > Configuration getConfiguration();
> > > Parameters getParameters();
> > > Context getContext();
> >
> > -1
> >
> > Same reason as above.
>
>Why not the above? The Javadoc for ComponentMetaData says:
>
> * Each component declared in the application is represented by
> * a ComponentMetaData. Note that this does not necessarily imply
> * that there is only one instance of actual component. The
> * ComponentMetaData could represent a pool of components, a single
> * component or a component prototype that is reused to create
> * new components as needed.
>
>That would imply that they do have the same
>Configuration/Parameters/etc.
They have the same Configuration/Parameters but could potentially have
different Logger, Context and ComponentManager instances. The -1 was only
meant to apply to getContext()
Thats similar to how fortress works yer?
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Component Metadata and Metainfo model
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@apache.org]
>
> >{
> > DependencyMetaData[] getDependencyData();
> > Logger getLogger();
>
> -1
> This should go into component entry not metadata as it is tied to a
> particular instance, not a profile.
>
> > Configuration getConfiguration();
> > Parameters getParameters();
> > Context getContext();
>
> -1
>
> Same reason as above.
Why not the above? The Javadoc for ComponentMetaData says:
* Each component declared in the application is represented by
* a ComponentMetaData. Note that this does not necessarily imply
* that there is only one instance of actual component. The
* ComponentMetaData could represent a pool of components, a single
* component or a component prototype that is reused to create
* new components as needed.
That would imply that they do have the same
Configuration/Parameters/etc.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component Metadata and Metainfo model
Posted by Peter Donald <pe...@apache.org>.
At 11:42 PM 7/4/2002 +0200, you wrote:
>Suggested interfaces
>--------------------
>This builds upon the current avalon containerkit package. Please don't
>worry too much about namespace at this point.
>
>package org.apache.excalibur.meta;
>
>/**
> * The assembly of object instances of a components
> * declared dependencies on other components, as well as dependency on a
> * Logger, Configuration, Parameters and Context.
> */
>interface MetaData
Never going to use an interface again for this. If you remember back about
1 1/2 years ago we separated out interface and implementations for the meta
classes. It sucked hugely.
>{
> DependencyMetaData[] getDependencyData();
> Logger getLogger();
-1
This should go into component entry not metadata as it is tied to a
particular instance, not a profile.
> Configuration getConfiguration();
> Parameters getParameters();
> Context getContext();
-1
Same reason as above.
/**
> * provides valuable information to assembler and end user about a
> * component.
> */
>interface ComponentDescriptor extends Descriptor
>{
> String getName();
> Version getVersion();
> String getDescription();
> String getDefaultRoleName();
-1 only makes sense in some containers. Thus it should be an attribute.
>/**
> * Provide information about a component-to-component dependency
> */
>interface DependencyDescriptor extends Descriptor
>{
> String getRole();
> Version getVersion();
>
> boolean isOptional();
> boolean isRequired();
> /* maybe...
> DependencyDescriptor getAlternative();
> boolean isAlternative( DependencyDescriptor descriptor );
> boolean betterAlternativeTo( DependencyDescriptor descriptor );
> */
-1
Selection criterion are context sensitive and can be relegated to a
particular container implementation.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>