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:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
