J Aaron Farr wrote:
Hello.
I'm not sure I understand the <attributes> tag for merlin meta-info. Haven't found much in the mailing list archives either. Can someone explain this or perhaps point me to some documentation?
Attributes can be declared within a component type and under several of the features exposed by a type. Attributes are simply named value pairs that can be used in customized container extensions. For example - if I have some container side code (e.g. a custom container, an extended appliance or block, a profile selector or appliance selector, this code can read the meta info attributes as a source supporting decisions.
For example:
<type>
<info>
<name>my-very-cool-component</name>
<attributes>
<attribute name="urn:me:some.key" value="some-value"/>
</attributes>
</info>
</type>The container side could use the presence of attributes and/or attribute value for given keys to determine things like selection, supplementary deployment actions, etc. It is simply a means by which the meta-info model can be extended without requiring the definition of a new meta info factory.
Merlin uses these attributes in a number of places as a means to extend the meta package to meet Merlin containment needs.
For example:-
A custom contextualization handler dependency declaration:
A context <context> declaration can contain a attributes block which declare a contextualization stage handler. This is done using the the following and a value corresponding to a classname of the contextualization handler interface that a container needs to resolve a handler for.
urn:assembly:lifecycle.context.strategy
A profile selector class declaration in a dependency:
A component <dependency> declaration can include at attribute defining the classname of a profile selector to be used when selecting from multiple profiles or appliances with the same service criteria.
urn:avalon:profile.selector
Declaration with a classic service declaration of the protocol used to establish a service:
A component type <service> descriptor can declare if if the service is provided through good old fashioned implementation, or potentially something else. For example, in the CORBA world the component need not be the source of the service - the actual service provision may be provided by a remote stub. For these sort of cases we need mechanisms for a component type to declare non-classic service establishment mechanisms so that we don't do silly things when attempting to verify the integrity of a component type.
urn:avalon:service.protocol
Declaration of a component lifestyle (including inside the info element attributes set).
urn:avalon:lifestyle
And naturally, a couple of attributes dealing with the ability to declare a custom appliance class and/or custom appliance factory:
urn:assembly:appliance.class urn:assembly:appliance.factory
Wow. Been asking a lot of questions lately. :)
And before you ask the next question - the answer is a "well, sort of here and there" but yes, I could do with some more formal pulling things together. Also, now that things have settled down on the core, some of the attributes could be rolled into the meta-info model which would improve documetation and clarity - e.g. lifestyle is a good candidate bacuase its not Merlin specific.
Cheers, Steve.
p.s. Yep - the attributes tag appears to be missing in the documetation of the meta-info breakdown. I think it would make sence to included it under a "common elements" heading within the "Meta Info" section of the docs.
:-)
SJM
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
