So does having "String ROLE = InterfaceName.class.getName();" doesn't matter.
The notion of ROLE has never been used within Merlin.
And how are roles resolved now in Merlin ?
Forget about the term "role" - think instead in terms "component", "services" and "dependencies. Any component compliant with the Avalon Meta package declares itself as a component by simply including @avalon.component at the class level (in fact that's not even a requirement - but that's another subject).
/**
* @avalon.component name="fred"
*/
public class Fred
{
}If the component has a dependency then the component needs to declare this using @avalon tags. Dependencies that are managed my Merlin include all deployment and runtime features that the Avalon Meta Model declares. These include classic service dependencies (accessible via a ServiceManager), context dependencies (accessible via a Context interface, derived context interface, or custom contextualization strategy), not to mention logging, parameterization and configuration dependencies, together with lifecycle stage dependencies.
Here is a simple addition to the above component to include a service dependency:
/**
* @avalon.component name="fred"
*/
public class Fred
{
private Gizmo m_gizmo; /**
* @avalon.dependency type="Gizmo" key="my-gizmo"
*/
public void service( ServiceManager manager )
throws ServiceException
{
m_gizmo = (Gizmo) manager.get( "my-gizmo" );
}
}The key things in the above example - the component is declaring explicitly that it needs a service that conforms to the Gizmo interface contract. Secondly, it is saying that it will lookup that service in the service manager using the key "my-gizmo". From here it is the containers responsibility to establish and associate the component relative to the requested key.
A complete description of the @avalon tags is available here:
http://avalon.apache.org/meta/tools/tags/index.html
The specification of the component type descriptors build from tags which provides binary component portability is defined here:
http://avalon.apache.org/meta/meta/info/type/index.html
An API supporting dynamic component type definition construction is available here:
http://avalon.apache.org/meta/api/index.html
The bottom line is ... if you can describe the contract using the @avalon tags you have source portability across any container that is compliant with the Avalon Meta standard. If you use the tools bundled with the package you can automatically escalate to binary component compatibility.
Finally, Merlin ... actually there isn't much to say. Merlin is based on the Avalon Meta Model, it defines a parallel architecture with respect to meta data management, a comprehensive model-driven architecture, and ultimately - an efficient and reliable runtime platform.
Cheers, Stephen.
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
