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:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to