avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [RT] SOC & Meta Information
Date Wed, 04 Sep 2002 14:06:07 GMT

Peter Donald wrote:
> On Wed, 4 Sep 2002 21:22, Peter Donald wrote:
> 
> 
>>>What I like about making services and components full meta types is
>>>summed
>>>up in two aspects: Service resolution and Service management interface
>>>publication.  We had talked in the past regarding attributes helping the
>>>container distinguish between multiple service implementations.  However
>>>there was no real way to validate the attributes, or use them in an
>>>automated fashion.  Here is what a service definition would allow us
>>>to do:
>>
>>I attributes slightly differently but I have similarly come up against the
>>limitations (lack of validation/definition).
>>
>>Anyways I tend to think of attributes as aspects rather than features of a
>>artefact. So I tend to think in terms of saying things like "Apply these
>>(persistence|transaction|remoting|security|instrumentation) attributes to
>>the method/interface/component etc." However you are marking them as
>>helping the selection criterion be narrowed for a component and so forth?
>>
>>For an example I have attached the set of attributes I have attempted to
>>boil down that are essentially container independent. The list used to
>>contain many more but I have moved them to different categories;
>>* toolkit specific (ie altrmi:*)
>>* container specific (ie phoenix:*)
>>* aspect specific (mx:*, persist:*) (Though I have barely looked at this
>>side of things)
>>
>>Anyway take a look at the list to see what I mean.
> 
> 
> And this time I made it into a jar so the list manager will not strip it.

Ah, I was still searching on the *mailing* list, thanks you found out 
the ... strip ;-)


Anyway, very nice! :-D
I also think that some of these can be checked compiletime, like 
stateless I think.

Some considerations:

- avalon:activation  I don't understand the implications completely, and 
we would need to define what a "partition" is, as said in previous mails.

- feature:required   I think I prefer this to feature:featurename, 
because it specifies if it's required, without semantics on how to 
declare it

- What's the difference between doc:description-key and doc:i18n-bundle? 
Can't we simply supply i18n bundles for the descriptions? If instead 
it's for the component to supply its i18nzed strings, it's not a doc: ...

I think I like this :-)
One thing is that I would like to see maybe

   avalon:activation ->  avalon:lifestyle.activation
   feature:required  ->  avalon:feature.required
   doc:description   ->  avalon:doc.description

or something like it, to prevent nasty clashing with eventual additional 
javadoc tags being used (especially feature and docs that are common words).

What about the method descriptions you were previously talking about?

Anyway, cool :-)

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


Mime
View raw message