avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Verifying Meta Tags
Date Tue, 08 Apr 2003 12:29:01 GMT
Stephen McConnell wrote:
>> It is my inderstanding that we are OK with the following tags:
>> On the service interface (optional):
>> @avalon.role -- marks role interfaces as a role/service directly
> What is the function of this tag - what does it generate in Fortress.  
> In the Merlin environment there are two tags that can be associated with 
> a interface.  These include the @avalon.meta.version tag, and the 
> possibly multiple @avalon.meta.attribute tags.  Given that you already 
> know that the interface is an interface, presumably you can focus on the 
> declaration of the "features" of the interface that you want to capture.

An interface is an interface--we all know that.  However what purpose
does the interface serve?  Is it a service that a component implements?
Is it a lifecycle extension?  Or is it a generic interface?

@avalon.role marks a work interface, or the role interface for a
component.  It is another style of marking that interface than the
@phoenix.service or @avalon.service approach, and one that I favor.

>> On the component implementation:
>> @avalon.component -- marks the class as a component 
> I have simpliar concerns about the @avalon.component tag to the above 
> comments concerns role.  We know that we are dealing with an 
> implementation class and we can detect if that class contains tagged 
> information.  I think it is more interesting to focus on qualifying the 
> features that are required and then triggering processing from those 
> features as opposed to using what is in effect a component market tag.  
> For example, the Merlin meta model requires that a version is declared 
> explicitly (in fact this is the only required tag).

Fortress is only concerned with the bare minimums.  It is not validating
the components.  It is only getting the components.  BTW, how do you
know which classes are components and which are just classes?

>> @avalon.service org.apache.ServiceName -- marks the specified interface
>>                                           as a role/service 
> Would prefer to see this as @avalon.service type="[type-defintion]" 
> where [type-defintion] = [classname]:[version] where version is  
> optional. See 
> http://avalon.apache.org/sandbox/merlin/tools/tags/service.html for an 
> example.

Both you and Peter seem to agree on this point--so I will adopt it.
However, I think that any version information should be its own

@avalon.service type="org.apache.FooService" version="1.2.0"

>> @x-avalon.lifecycle singleton -- Marks the lifestyle of the component
>>                                  (should be changed to lifestyle) 
> Loks fine - can you confirm if you using the same arguments as the 
> Merlin package:
> http://avalon.apache.org/sandbox/merlin/tools/tags/lifestyle.html

Should be either @x-avalon.lifestyle or
@x-avalon.lifecycle style="singleton"

So which is preferable?

>> @x-avalon.name component-name -- Configuration short name and debug name

> I would use "name" in preference to "component-name".
> See http://avalon.apache.org/sandbox/merlin/tools/tags/name.html


"component-name" is just whatever you want for the configuration name.
If I want hyphens then that is what I use.  If you like dots, that is
what you use.  It is a matter of preference.  Although colons ":" are
not allowed unless you are using a namespace.

"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".

-----Chris Rock

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message