Guys,
What do you say to just getting rid of this silly ROLE constant?
If Merlin does not use it and we have Avalon meta for the tagging
of components then why bother with ROLE I say. Let's get rid of
it once and for all making it official here:
[X] Say no to ROLE constant
[ ] Keep it
Alex
>
> From: Stephen McConnell <[EMAIL PROTECTED]>
> Date: 2004/01/16 Fri PM 08:32:22 EST
> To: Avalon framework users <[EMAIL PROTECTED]>
> Subject: Re: Roles and Components in Merlin : another newbie
>
> Mathews Julien wrote:
>
> > 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
