You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <pe...@apache.org> on 2002/06/06 05:31:22 UTC
ContainerKits Meta data/info
Hi,
I have just completed the first draft of the MetaData and MetaInfo objects
for container writers. I would appreciate if all you container writers
(particularly Berin, Leo and Stephen) would look at the classes in
org.apache.excalibur.containerkit.metadata
org.apache.excalibur.containerkit.metainfo
The metainfo classes are meta information about the component type.
Basically it contains information such as
* what services does component support
* what services does component require to operate
* generic information (like classname of component and version of component)
The metadata contains basic information about a "assembled" component.
Basically it is the mapping of component dependencies. ie Component A
provides service P to Component B
The metainfo should be sufficient to model all our containers. When a
container requires specific capabilities (ie Merlins constraints or
Fortresses lifestyles) it can use "attributes". Attributes are basically
opaque strings that describe container specific things (See javadocs of the
classes). The metainfo classes should not need to be subclassed.
In the future metainfo will probably include things like;
* configuration/parameters schema (maybe XML Schema?)
* required context values (Basically like resource-ref from J2EE world)
The metadata package will probably need to be subclassed to provide
container specific information but it is a start.
So what do you think? Is there anything else that it needs to support for
it to be useful in all containers?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ContainerKits Meta data/info
Posted by Peter Royal <pr...@apache.org>.
On Thursday 06 June 2002 08:55 pm, Peter Donald wrote:
> >(Getting a bit more phoenix specific here...) I think that would be useful
> >because if we allow a SAR to contain incomplete config information that
> > must be supplied by the admin via the console before an app could be
> > started, we could still validate the incomplete configuration information
> > in the SAR.
>
> That could be good. Alternatively we could just change it so that
> configuration is not validated when deployed and instead validated just
> prior to starting app. BTW we could also use an XML snippet that sits
That would also work, but I'd prefer to be as upfront about error as we can
possibly be.
> side-by-side to Block as basic deployment info if it is not present in
> config.xml. Like?
Very nice!
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ContainerKits Meta data/info
Posted by Peter Donald <pe...@apache.org>.
At 09:34 AM 6/6/2002 -0400, you wrote:
>I've been thinking about configuration schema (yes i finally started on the
>console bits for phoenix),
yay!
>and I was looking at RELAX-NG, and specifically
>the Jing library (http://www.thaiopensource.com/relaxng/jing.html). One
>thing that appealed to me was the ability to validate a document as "feasibly
>valid".
kool.
>(Getting a bit more phoenix specific here...) I think that would be useful
>because if we allow a SAR to contain incomplete config information that must
>be supplied by the admin via the console before an app could be started, we
>could still validate the incomplete configuration information in the SAR.
That could be good. Alternatively we could just change it so that
configuration is not validated when deployed and instead validated just
prior to starting app. BTW we could also use an XML snippet that sits
side-by-side to Block as basic deployment info if it is not present in
config.xml. Like?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ContainerKits Meta data/info
Posted by Peter Royal <pr...@apache.org>.
On Wednesday 05 June 2002 11:31 pm, Peter Donald wrote:
> In the future metainfo will probably include things like;
> * configuration/parameters schema (maybe XML Schema?)
...
> So what do you think? Is there anything else that it needs to support for
> it to be useful in all containers?
Basically agreeing with LS, I looked over it all and at a glance it appears
nice and clean. We'll have to see how implementations go.
I've been thinking about configuration schema (yes i finally started on the
console bits for phoenix), and I was looking at RELAX-NG, and specifically
the Jing library (http://www.thaiopensource.com/relaxng/jing.html). One
thing that appealed to me was the ability to validate a document as "feasibly
valid".
(Getting a bit more phoenix specific here...) I think that would be useful
because if we allow a SAR to contain incomplete config information that must
be supplied by the admin via the console before an app could be started, we
could still validate the incomplete configuration information in the SAR.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ContainerKits Meta data/info
Posted by Stephen McConnell <mc...@osm.net>.
Stephen McConnell wrote:
>
> OK.
Its done.
Take a look at the following UML for how the restructuring looks:
http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-avalon-excalibur/containerkit/src/doc/model.gif?rev=1.1
Have reverted to final clsses and added a getAttributeNames accessor
where appropriate.
I also validated the build on Phoenix with the new jar.
Cheers, Steve.
>
>
> Peter Donald wrote:
>
>> At 02:21 AM 6/7/2002 +0200, you wrote:
>> > However, there is a question I raised in that email thats
>> independent of that issue - namely the redundancy of attributes on
>> the service
>> > descriptor contained by a depedebncy declaration - I think the
>> definition should be revised to something like a service reference.
>>
>> Hmm - maybe a good idea. Want to do it? ;)
>>
>>
>> --
>> 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: ContainerKits Meta data/info
Posted by Stephen McConnell <mc...@osm.net>.
OK.
Peter Donald wrote:
> At 02:21 AM 6/7/2002 +0200, you wrote:
> > However, there is a question I raised in that email thats
> independent of that issue - namely the redundancy of attributes on the
> service
> > descriptor contained by a depedebncy declaration - I think the
> definition should be revised to something like a service reference.
>
> Hmm - maybe a good idea. Want to do it? ;)
>
>
> --
> 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: ContainerKits Meta data/info
Posted by Peter Donald <pe...@apache.org>.
At 02:21 AM 6/7/2002 +0200, you wrote:
> However, there is a question I raised in that email thats independent of
that issue - namely the redundancy of attributes on the service
> descriptor contained by a depedebncy declaration - I think the
definition should be revised to something like a service reference.
Hmm - maybe a good idea. Want to do it? ;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ContainerKits Meta data/info
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
> Hi,
>
> I think you are confusing my intentions about attrributes. They are
> purely an escape mechanism for container specific information.
>
> * Attributes on services do not necessarily denote extra capabilities.
> * Attributes on dependencies do not necessarily denote constraints.
>
> The attributes are purely directives to container for container
> specific features. For instance you could mark a service as capable of
> being "remoteable" which would mean you could export it via
> WebService, CORBA, AltRMI etc.
>
> We may eventually create a standard set of meta-tags but until such a
> time they are completely container dependent. The "availability"
> attribute in batman may mean something completely and utterly
> different from gotham-citys use of "availability"
I agree - I cut-and-pasted the example from another email I havn't sent
that was preparing question about exactly the point you talking about -
what do attributes mean to the different actors involved. The email
hasn't been sent because I havn't figured out yet what the corresponding
scenario is between the Merlin assembly delcarations, component
attributes, service attributes and dependecy attributes. However, there
is a question I raised in that email thats independent of that issue -
namely the redundancy of attributes on the service descriptor contained
by a depedebncy declaration - I think the definition should be revised
to something like a service reference.
Cheers, Steve.
>
>
>
> At 01:10 AM 6/7/2002 +0200, you wrote:
>
>> A couple of questions concering DependencyDescriptor and
>> ServiceDescriptor:
>>
>> 1. If I have a component declaration such as:
>>
>> <block>
>> <name>batman</name>
>> <version>12.0</version>
>> <attributes>
>> <attribute name="alias" value="Bruce Wayne"/>
>> </attributes>
>> </block>
>>
>> <services>
>> <service name="org.apache.TruthAndJustice" version="2.3">
>> <attribute name="availablilty" value="7x8"/>
>> </service>
>> </service>
>>
>> and a second component that is dependent on the above component:
>>
>> <block>
>> <name>gotham-city</name>
>> <version>1.5</version>
>> </block>
>>
>> <dependecies>
>> <dependecy>
>> <role>superhero</role>
>> <service name="org.apache.TruthAndJustice" version="2.3"/>
>> <constraints>
>> <constraint name="availablilty" value="7x24"/>
>> </constraints>
>> </dependecy>
>> </dependecies>
>>
>> The service declaration under the dependency is actually a service
>> reference in that it does not make any sense for this to include
>> attribute declarations. Would it not be better to sperate a
>> service descriptor reference from the actual descriptor?
>>
>> E.g.:
>>
>> ServiceReference { String m_name, Version m_version }
>> ^
>> | [extends]
>> |
>> ServiceDescriptor { Properties m_attributes }
>>
>> And from this, DependecyDescriptor could be more correctly defined as
>>
>> DependencyDescriptor { String m_role, ServiceReference m_service,
>> Properties m_constraints }
>>
>> 2. The second thing that pops up is the method name getAttribute in
>> DependecyDescriptor - I think this should be renamed to getConstraint.
>>
>> 3. ServiceDescriptor is declared as a final class - is this necessary?
>> In particular I would need to extend this to handle extraction of
>> declared properties.
>>
>> Cheers, Steve.
>>
>>
>>
>> Peter Donald wrote:
>>
>>> Hi,
>>>
>>> I have just completed the first draft of the MetaData and MetaInfo
>>> objects for container writers. I would appreciate if all you
>>> container writers (particularly Berin, Leo and Stephen) would look
>>> at the classes in
>>>
>>> org.apache.excalibur.containerkit.metadata
>>> org.apache.excalibur.containerkit.metainfo
>>>
>>> The metainfo classes are meta information about the component type.
>>> Basically it contains information such as
>>> * what services does component support
>>> * what services does component require to operate
>>> * generic information (like classname of component and version of
>>> component)
>>>
>>> The metadata contains basic information about a "assembled"
>>> component. Basically it is the mapping of component dependencies. ie
>>> Component A provides service P to Component B
>>>
>>> The metainfo should be sufficient to model all our containers. When
>>> a container requires specific capabilities (ie Merlins constraints
>>> or Fortresses lifestyles) it can use "attributes". Attributes are
>>> basically opaque strings that describe container specific things
>>> (See javadocs of the classes). The metainfo classes should not need
>>> to be subclassed.
>>>
>>> In the future metainfo will probably include things like;
>>> * configuration/parameters schema (maybe XML Schema?)
>>> * required context values (Basically like resource-ref from J2EE world)
>>>
>>> The metadata package will probably need to be subclassed to provide
>>> container specific information but it is a start.
>>>
>>> So what do you think? Is there anything else that it needs to
>>> support for it to be useful in all containers?
>>>
>>>
>>> --
>>> 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: ContainerKits Meta data/info
Posted by Peter Donald <pe...@apache.org>.
Hi,
I think you are confusing my intentions about attrributes. They are purely
an escape mechanism for container specific information.
* Attributes on services do not necessarily denote extra capabilities.
* Attributes on dependencies do not necessarily denote constraints.
The attributes are purely directives to container for container specific
features. For instance you could mark a service as capable of being
"remoteable" which would mean you could export it via WebService, CORBA,
AltRMI etc.
We may eventually create a standard set of meta-tags but until such a time
they are completely container dependent. The "availability" attribute in
batman may mean something completely and utterly different from
gotham-citys use of "availability"
At 01:10 AM 6/7/2002 +0200, you wrote:
>A couple of questions concering DependencyDescriptor and ServiceDescriptor:
>
>1. If I have a component declaration such as:
>
> <block>
> <name>batman</name>
> <version>12.0</version>
> <attributes>
> <attribute name="alias" value="Bruce Wayne"/>
> </attributes>
> </block>
>
> <services>
> <service name="org.apache.TruthAndJustice" version="2.3">
> <attribute name="availablilty" value="7x8"/>
> </service>
> </service>
>
> and a second component that is dependent on the above component:
>
> <block>
> <name>gotham-city</name>
> <version>1.5</version>
> </block>
>
> <dependecies>
> <dependecy>
> <role>superhero</role>
> <service name="org.apache.TruthAndJustice" version="2.3"/>
> <constraints>
> <constraint name="availablilty" value="7x24"/>
> </constraints>
> </dependecy>
> </dependecies>
>
> The service declaration under the dependency is actually a service
> reference in that it does not make any sense for this to include
> attribute declarations. Would it not be better to sperate a
> service descriptor reference from the actual descriptor?
>
> E.g.:
>
> ServiceReference { String m_name, Version m_version }
> ^
> | [extends]
> |
> ServiceDescriptor { Properties m_attributes }
>
> And from this, DependecyDescriptor could be more correctly defined as
>
> DependencyDescriptor { String m_role, ServiceReference m_service,
> Properties m_constraints }
>
>2. The second thing that pops up is the method name getAttribute in
> DependecyDescriptor - I think this should be renamed to getConstraint.
>
>3. ServiceDescriptor is declared as a final class - is this necessary?
> In particular I would need to extend this to handle extraction of
> declared properties.
>
>Cheers, Steve.
>
>
>
>Peter Donald wrote:
>
>>Hi,
>>
>>I have just completed the first draft of the MetaData and MetaInfo
>>objects for container writers. I would appreciate if all you container
>>writers (particularly Berin, Leo and Stephen) would look at the classes in
>>
>>org.apache.excalibur.containerkit.metadata
>>org.apache.excalibur.containerkit.metainfo
>>
>>The metainfo classes are meta information about the component type.
>>Basically it contains information such as
>>* what services does component support
>>* what services does component require to operate
>>* generic information (like classname of component and version of component)
>>
>>The metadata contains basic information about a "assembled" component.
>>Basically it is the mapping of component dependencies. ie Component A
>>provides service P to Component B
>>
>>The metainfo should be sufficient to model all our containers. When a
>>container requires specific capabilities (ie Merlins constraints or
>>Fortresses lifestyles) it can use "attributes". Attributes are basically
>>opaque strings that describe container specific things (See javadocs of
>>the classes). The metainfo classes should not need to be subclassed.
>>
>>In the future metainfo will probably include things like;
>>* configuration/parameters schema (maybe XML Schema?)
>>* required context values (Basically like resource-ref from J2EE world)
>>
>>The metadata package will probably need to be subclassed to provide
>>container specific information but it is a start.
>>
>>So what do you think? Is there anything else that it needs to support for
>>it to be useful in all containers?
>>
>>
>>--
>>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: ContainerKits Meta data/info
Posted by Stephen McConnell <mc...@osm.net>.
A couple of questions concering DependencyDescriptor and ServiceDescriptor:
1. If I have a component declaration such as:
<block>
<name>batman</name>
<version>12.0</version>
<attributes>
<attribute name="alias" value="Bruce Wayne"/>
</attributes>
</block>
<services>
<service name="org.apache.TruthAndJustice" version="2.3">
<attribute name="availablilty" value="7x8"/>
</service>
</service>
and a second component that is dependent on the above component:
<block>
<name>gotham-city</name>
<version>1.5</version>
</block>
<dependecies>
<dependecy>
<role>superhero</role>
<service name="org.apache.TruthAndJustice" version="2.3"/>
<constraints>
<constraint name="availablilty" value="7x24"/>
</constraints>
</dependecy>
</dependecies>
The service declaration under the dependency is actually a service
reference in that it does not make any sense for this to include
attribute declarations. Would it not be better to sperate a
service descriptor reference from the actual descriptor?
E.g.:
ServiceReference { String m_name, Version m_version }
^
| [extends]
|
ServiceDescriptor { Properties m_attributes }
And from this, DependecyDescriptor could be more correctly defined as
DependencyDescriptor { String m_role, ServiceReference m_service,
Properties m_constraints }
2. The second thing that pops up is the method name getAttribute in
DependecyDescriptor - I think this should be renamed to getConstraint.
3. ServiceDescriptor is declared as a final class - is this necessary?
In particular I would need to extend this to handle extraction of
declared properties.
Cheers, Steve.
Peter Donald wrote:
> Hi,
>
> I have just completed the first draft of the MetaData and MetaInfo
> objects for container writers. I would appreciate if all you container
> writers (particularly Berin, Leo and Stephen) would look at the
> classes in
>
> org.apache.excalibur.containerkit.metadata
> org.apache.excalibur.containerkit.metainfo
>
> The metainfo classes are meta information about the component type.
> Basically it contains information such as
> * what services does component support
> * what services does component require to operate
> * generic information (like classname of component and version of
> component)
>
> The metadata contains basic information about a "assembled" component.
> Basically it is the mapping of component dependencies. ie Component A
> provides service P to Component B
>
> The metainfo should be sufficient to model all our containers. When a
> container requires specific capabilities (ie Merlins constraints or
> Fortresses lifestyles) it can use "attributes". Attributes are
> basically opaque strings that describe container specific things (See
> javadocs of the classes). The metainfo classes should not need to be
> subclassed.
>
> In the future metainfo will probably include things like;
> * configuration/parameters schema (maybe XML Schema?)
> * required context values (Basically like resource-ref from J2EE world)
>
> The metadata package will probably need to be subclassed to provide
> container specific information but it is a start.
>
> So what do you think? Is there anything else that it needs to support
> for it to be useful in all containers?
>
>
> --
> 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: ContainerKits Meta data/info
Posted by Peter Donald <pe...@apache.org>.
Sounds fine to me.
At 05:39 PM 6/6/2002 +0200, you wrote:
>Seems to me that ResourceAccessor should be renamed to ResourceProvider.
>
>Steve.
>
>
>Peter Donald wrote:
>
>>Hi,
>>
>>I have just completed the first draft of the MetaData and MetaInfo
>>objects for container writers. I would appreciate if all you container
>>writers (particularly Berin, Leo and Stephen) would look at the classes in
>>
>>org.apache.excalibur.containerkit.metadata
>>org.apache.excalibur.containerkit.metainfo
>>
>>The metainfo classes are meta information about the component type.
>>Basically it contains information such as
>>* what services does component support
>>* what services does component require to operate
>>* generic information (like classname of component and version of component)
>>
>>The metadata contains basic information about a "assembled" component.
>>Basically it is the mapping of component dependencies. ie Component A
>>provides service P to Component B
>>
>>The metainfo should be sufficient to model all our containers. When a
>>container requires specific capabilities (ie Merlins constraints or
>>Fortresses lifestyles) it can use "attributes". Attributes are basically
>>opaque strings that describe container specific things (See javadocs of
>>the classes). The metainfo classes should not need to be subclassed.
>>
>>In the future metainfo will probably include things like;
>>* configuration/parameters schema (maybe XML Schema?)
>>* required context values (Basically like resource-ref from J2EE world)
>>
>>The metadata package will probably need to be subclassed to provide
>>container specific information but it is a start.
>>
>>So what do you think? Is there anything else that it needs to support for
>>it to be useful in all containers?
>>
>>
>>--
>>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: ContainerKits Meta data/info
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
a) SLOW DOWN. :)
b) Looks fine. Whatever limitations the classes have will come up
when trying to use them.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ContainerKits Meta data/info
Posted by Peter Donald <pe...@apache.org>.
And now I have updated the ContainerKit lifecyle package. Basically this
helps with running components through lifecyle. It makes sure that the
correct order is followed as well as adding lots more logging and error
catching code.
To use this you would implement the ResourceAccessor interface. It is
responsible for creating all the resources (context, serviceManager etc)
for component (and also responsible for creating component itself). Each of
the methods take an Object parameter.
Each container is likely to pass a different object into ResourceAccessor.
Phoenix passes a BlockEntry object while myrmidon will like pass in the
ComponentInfo object. You use this key to lcoate resources for specifific
component and away you go.
If someone could have a look at rewrite ComponentFactory in Fortress to use
it then that would be great.
At 01:54 PM 6/6/2002 +1000, you wrote:
>Hi,
>
>The verifier package is also something to look at now. Basically it
>validates a number of rules for avalon components. Some of the rules may
>not be relevent for a particular container (like requirement that classes
>be public or have no args constructors) in which caseyou can overide the
>particular method that checks that rule so that it is a no-op.
>
>Comments on the rules, which up until now have largely been unspoken rules
>or only partially enforced. Feel free to disagree about them if you want ;)
>
>At 01:31 PM 6/6/2002 +1000, you wrote:
>>Hi,
>>
>>I have just completed the first draft of the MetaData and MetaInfo
>>objects for container writers. I would appreciate if all you container
>>writers (particularly Berin, Leo and Stephen) would look at the classes in
>>
>>org.apache.excalibur.containerkit.metadata
>>org.apache.excalibur.containerkit.metainfo
>>
>>The metainfo classes are meta information about the component type.
>>Basically it contains information such as
>>* what services does component support
>>* what services does component require to operate
>>* generic information (like classname of component and version of component)
>>
>>The metadata contains basic information about a "assembled" component.
>>Basically it is the mapping of component dependencies. ie Component A
>>provides service P to Component B
>>
>>The metainfo should be sufficient to model all our containers. When a
>>container requires specific capabilities (ie Merlins constraints or
>>Fortresses lifestyles) it can use "attributes". Attributes are basically
>>opaque strings that describe container specific things (See javadocs of
>>the classes). The metainfo classes should not need to be subclassed.
>>
>>In the future metainfo will probably include things like;
>>* configuration/parameters schema (maybe XML Schema?)
>>* required context values (Basically like resource-ref from J2EE world)
>>
>>The metadata package will probably need to be subclassed to provide
>>container specific information but it is a start.
>>
>>So what do you think? Is there anything else that it needs to support for
>>it to be useful in all containers?
>>
>>
>>--
>>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>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ContainerKits Meta data/info
Posted by Stephen McConnell <mc...@osm.net>.
Seems to me that ResourceAccessor should be renamed to ResourceProvider.
Steve.
Peter Donald wrote:
> Hi,
>
> I have just completed the first draft of the MetaData and MetaInfo
> objects for container writers. I would appreciate if all you container
> writers (particularly Berin, Leo and Stephen) would look at the
> classes in
>
> org.apache.excalibur.containerkit.metadata
> org.apache.excalibur.containerkit.metainfo
>
> The metainfo classes are meta information about the component type.
> Basically it contains information such as
> * what services does component support
> * what services does component require to operate
> * generic information (like classname of component and version of
> component)
>
> The metadata contains basic information about a "assembled" component.
> Basically it is the mapping of component dependencies. ie Component A
> provides service P to Component B
>
> The metainfo should be sufficient to model all our containers. When a
> container requires specific capabilities (ie Merlins constraints or
> Fortresses lifestyles) it can use "attributes". Attributes are
> basically opaque strings that describe container specific things (See
> javadocs of the classes). The metainfo classes should not need to be
> subclassed.
>
> In the future metainfo will probably include things like;
> * configuration/parameters schema (maybe XML Schema?)
> * required context values (Basically like resource-ref from J2EE world)
>
> The metadata package will probably need to be subclassed to provide
> container specific information but it is a start.
>
> So what do you think? Is there anything else that it needs to support
> for it to be useful in all containers?
>
>
> --
> 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: ContainerKits Meta data/info
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
> At 10:38 PM 6/6/2002 +0200, you wrote:
>
>> A couple of questions concerning ComponentInfo:
>>
>> 1. displayname
>>
>> Is it a more friendly name that the name state member.
>
>
> yep
>
>> E.g.
>>
>> name = "my-component"
>> displayName = "My Component"
>>
>> And concerning the schema for displayname:
>>
>> <block>
>> <name>my-block</name>
>> <displayname>My Block</displayname> ??
>> </block>
>>
>> I'm also assuming that <name> will have specific
>> restrictions over and above <displayname> - e.g. no
>> period (enabling the use of the name as the default
>> logging catagory child name).
>
>
>
> Check ComponentVerifier.isValidNam - I wrote that code about a year
> ago and my memory is a bit fuzzy. I believe names can be
> uppercase/lowercase letter, numbers or the '-' character (and maybe '_').
>
>> 2. what is schema for "property" declarations within a <block>
>
>
> Property? You mean attribute declarations?
Yes.
> None as of yet - haven't got to doing the serialized format of info
> files. Goto go have a gander at coocoon stuff before I try to do that ;)
Ok, in the meantime I'm assume the following:
<attributes>
<atttribute name="xxx" value="yyy"/>
</attributes>
>
>
>> And a question concerning attributes - the ComponentInfo class (and
>> other classes exposing attributes) do not allow access to the set of
>> property names. Is there a reason for this.
>
>
> They used to - then I deleted it because I wasn't sure it was a good
> idea. It could allow containers to just randomly go through the
> attributes and try to interpret them rather than just processing the
> ones it knows. I could re-add it if you like?
I think its needed - something like String[] getAttributeNames(). What
I'm thinking about is the ability for a tool to present component meta
info and the presentation should include the attributes. If you put in
you could finalize the class again :-)
Cheers, Steve.
>
>
>
> --
> 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: ContainerKits Meta data/info
Posted by Stephen McConnell <mc...@osm.net>.
Stephen McConnell wrote:
>
>
> Peter Donald wrote:
>
>> At 10:38 PM 6/6/2002 +0200, you wrote:
>>
>>> A couple of questions concerning ComponentInfo:
>>>
>>> 1. displayname
>>>
>>> Is it a more friendly name that the name state member.
>>
>>
>>
>> yep
>>
>>> E.g.
>>>
>>> name = "my-component"
>>> displayName = "My Component"
>>>
>>> And concerning the schema for displayname:
>>>
>>> <block>
>>> <name>my-block</name>
>>> <displayname>My Block</displayname> ??
>>> </block>
>>>
>>> I'm also assuming that <name> will have specific
>>> restrictions over and above <displayname> - e.g. no
>>> period (enabling the use of the name as the default
>>> logging catagory child name).
>>
>>
>>
>>
>> Check ComponentVerifier.isValidNam - I wrote that code about a year
>> ago and my memory is a bit fuzzy. I believe names can be
>> uppercase/lowercase letter, numbers or the '-' character (and maybe
>> '_').
>
>
>
> The current version of ComponentVerifier does not do any name
> validation - that code is over in Phoenix. I propose we lift
> SarVerifier.isValidName( String name ) and place it inside
> ComponentVerifier.
Correction - there is a verifyValidNames in AssemblyVerifier.
(steve's still digging around)
>
>
> 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: ContainerKits Meta data/info
Posted by Peter Donald <pe...@apache.org>.
At 07:57 AM 6/8/2002 +0200, you wrote:
> The current version of ComponentVerifier does not do any name validation
- that code is over in Phoenix. I propose we lift
> SarVerifier.isValidName( String name ) and place it inside
ComponentVerifier.
Hmm .. actually I believe it could be in AssemblyVerifier as the
ComponentVerifier is unaware of any concepts of metainfo/metadata - only
the AssemblyVerifier is aware of those constraints.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ContainerKits Meta data/info
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
> At 10:38 PM 6/6/2002 +0200, you wrote:
>
>> A couple of questions concerning ComponentInfo:
>>
>> 1. displayname
>>
>> Is it a more friendly name that the name state member.
>
>
> yep
>
>> E.g.
>>
>> name = "my-component"
>> displayName = "My Component"
>>
>> And concerning the schema for displayname:
>>
>> <block>
>> <name>my-block</name>
>> <displayname>My Block</displayname> ??
>> </block>
>>
>> I'm also assuming that <name> will have specific
>> restrictions over and above <displayname> - e.g. no
>> period (enabling the use of the name as the default
>> logging catagory child name).
>
>
>
> Check ComponentVerifier.isValidNam - I wrote that code about a year
> ago and my memory is a bit fuzzy. I believe names can be
> uppercase/lowercase letter, numbers or the '-' character (and maybe '_').
The current version of ComponentVerifier does not do any name validation
- that code is over in Phoenix. I propose we lift
SarVerifier.isValidName( String name ) and place it inside
ComponentVerifier.
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: ContainerKits Meta data/info
Posted by Peter Donald <pe...@apache.org>.
At 10:38 PM 6/6/2002 +0200, you wrote:
>A couple of questions concerning ComponentInfo:
>
> 1. displayname
>
> Is it a more friendly name that the name state member.
yep
> E.g.
>
> name = "my-component"
> displayName = "My Component"
>
> And concerning the schema for displayname:
>
> <block>
> <name>my-block</name>
> <displayname>My Block</displayname> ??
> </block>
>
> I'm also assuming that <name> will have specific
> restrictions over and above <displayname> - e.g. no
> period (enabling the use of the name as the default
> logging catagory child name).
Check ComponentVerifier.isValidNam - I wrote that code about a year ago and
my memory is a bit fuzzy. I believe names can be uppercase/lowercase
letter, numbers or the '-' character (and maybe '_').
> 2. what is schema for "property" declarations within a <block>
Property? You mean attribute declarations? None as of yet - haven't got to
doing the serialized format of info files. Goto go have a gander at coocoon
stuff before I try to do that ;)
>And a question concerning attributes - the ComponentInfo class (and other
>classes exposing attributes) do not allow access to the set of property
>names. Is there a reason for this.
They used to - then I deleted it because I wasn't sure it was a good idea.
It could allow containers to just randomly go through the attributes and
try to interpret them rather than just processing the ones it knows. I
could readd it if you like?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ContainerKits Meta data/info
Posted by Stephen McConnell <mc...@osm.net>.
A couple of questions concerning ComponentInfo:
1. displayname
Is it a more friendly name that the name state member.
E.g.
name = "my-component"
displayName = "My Component"
And concerning the schema for displayname:
<block>
<name>my-block</name>
<displayname>My Block</displayname> ??
</block>
I'm also assuming that <name> will have specific
restrictions over and above <displayname> - e.g. no
period (enabling the use of the name as the default
logging catagory child name).
2. what is schema for "property" declarations within a <block>
<block>
<properties>
<property name="xxx" value="yyyy"/> ???
</properties>
</block>
And a question concerning attributes - the ComponentInfo class (and
other classes exposing attributes) do not allow access to the set of
property names. Is there a reason for this.
Cheers, Steve.
Peter Donald wrote:
> Hi,
>
> I have just completed the first draft of the MetaData and MetaInfo
> objects for container writers. I would appreciate if all you container
> writers (particularly Berin, Leo and Stephen) would look at the
> classes in
>
> org.apache.excalibur.containerkit.metadata
> org.apache.excalibur.containerkit.metainfo
>
> The metainfo classes are meta information about the component type.
> Basically it contains information such as
> * what services does component support
> * what services does component require to operate
> * generic information (like classname of component and version of
> component)
>
> The metadata contains basic information about a "assembled" component.
> Basically it is the mapping of component dependencies. ie Component A
> provides service P to Component B
>
> The metainfo should be sufficient to model all our containers. When a
> container requires specific capabilities (ie Merlins constraints or
> Fortresses lifestyles) it can use "attributes". Attributes are
> basically opaque strings that describe container specific things (See
> javadocs of the classes). The metainfo classes should not need to be
> subclassed.
>
> In the future metainfo will probably include things like;
> * configuration/parameters schema (maybe XML Schema?)
> * required context values (Basically like resource-ref from J2EE world)
>
> The metadata package will probably need to be subclassed to provide
> container specific information but it is a start.
>
> So what do you think? Is there anything else that it needs to support
> for it to be useful in all containers?
>
>
> --
> 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: ContainerKits Meta data/info
Posted by Peter Donald <pe...@apache.org>.
Hi,
The verifier package is also something to look at now. Basically it
validates a number of rules for avalon components. Some of the rules may
not be relevent for a particular container (like requirement that classes
be public or have no args constructors) in which caseyou can overide the
particular method that checks that rule so that it is a no-op.
Comments on the rules, which up until now have largely been unspoken rules
or only partially enforced. Feel free to disagree about them if you want ;)
At 01:31 PM 6/6/2002 +1000, you wrote:
>Hi,
>
>I have just completed the first draft of the MetaData and MetaInfo objects
>for container writers. I would appreciate if all you container writers
>(particularly Berin, Leo and Stephen) would look at the classes in
>
>org.apache.excalibur.containerkit.metadata
>org.apache.excalibur.containerkit.metainfo
>
>The metainfo classes are meta information about the component type.
>Basically it contains information such as
>* what services does component support
>* what services does component require to operate
>* generic information (like classname of component and version of component)
>
>The metadata contains basic information about a "assembled" component.
>Basically it is the mapping of component dependencies. ie Component A
>provides service P to Component B
>
>The metainfo should be sufficient to model all our containers. When a
>container requires specific capabilities (ie Merlins constraints or
>Fortresses lifestyles) it can use "attributes". Attributes are basically
>opaque strings that describe container specific things (See javadocs of
>the classes). The metainfo classes should not need to be subclassed.
>
>In the future metainfo will probably include things like;
>* configuration/parameters schema (maybe XML Schema?)
>* required context values (Basically like resource-ref from J2EE world)
>
>The metadata package will probably need to be subclassed to provide
>container specific information but it is a start.
>
>So what do you think? Is there anything else that it needs to support for
>it to be useful in all containers?
>
>
>--
>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>