avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinay Chandran <vinay...@yahoo.com>
Subject Re: [AMTAGS] Updating the spec
Date Tue, 22 Jul 2003 06:55:27 GMT
Inline:
--- Stephen McConnell <mcconnell@apache.org> wrote:
> 
> The current named value approach is simple while not
> excluding evolution 
> along the lines your suggesting.  However, in the
> short term I see a 
> couple of downsides - (a) it would lead to a
> non-validatable schema (at 
> least non-validatable via a DTD), 

This shall be validated by the consumer.

> and (b) it would
> delay finalizing the 
> model.

Fine.

> My own usage
> of attributes has 
> been almost always as a way of sneaking in something
> as part of more 
> adventurous development.

Interesting... 
Its exactly the reason I am trying to use attributes
(service attributes to be specific).

> When the notion matures it
> will stand a good 
> chance of either escalating up to a formal element
> in the model (e.g. 
> lifestyle attributes is an example of something that
> started of as a 
> attribute and escalated to a formal element) or
> becoming a recognized 
> attribute (e.g. something life local or remote
> service is an example of 
> a candidate for a standard attribute - but after
> some general experience 
> with distributed service management).
> 

Umm!!! Exactly the piece I am trying to build.
I have created a simple custom appliance 
that reads the service descriptors of the contained
type. (done)
It shall then make sense out of the declared
service  attributes of the type to export/expose the
custom service's namely
services with specific(i.e.  urn:service:handler)
service attributes (todo).

So here how my component using a custom appliance
looks like:
<type>
 <info>
  <name>exposed</name>
  <!-- Here is my CustomAppliance for my type of
component -->
  <attributes>
    <attribute key="urn:assembly:appliance.class"
value="org.apache.avalon.playground.appliance.RichAppliance"/>
  </attributes>
 </info>
 <services>
   <service type="vinay.CustomService"/>
   <service type="vinay.CustomService">
     <attributes>
       <!-- THIS IS THE PLACE WHERE I WOULD HAVE LIKED
A EXPRESSIVE ATTRIBUTE DESCRIPTOR.SINCE THEN I COULD
HAVE
	EMBEDDED A LOT OF USEFUL METADATA TO CONFIGURE THE
APPLIANCE ASSOCIATED WITH THIS TYPE.
 	THIS CURRENTLY LOOKS LIKE A HACK. 
        -->
       <attribute key="urn:service:handler.altrmi"
value="Placeholder"/>

     </attribute>
  </service>
  <service type="vinay.OtherService">
      <!-- THIS CONTRACT IS NOT VISIBLE AMONG OTHER
COMPONENTS AND IS PRESENTED ONLY TO THE
EXTRATERRESTRIAL
       WORLD OF CONSUMERS OUTSIDE THE AVALON
DOMAIN(altrmi consumers in this case). 
      -->
     <attributes>
       <attribute key="urn:service:handler.altrmi"
value="Placeholder"/>
     </attribute>
  </service>

 </services>
</type>


It would be neat if I could merely declare a attribute
(without value) or maybe also provide a means
to embedd data within <attribute/>, validation being a
responsibility of the consumer (RichAppliance) in this
case.

'urn:service:handler' key is nothing but the ROLE for
an AltrmiProvider component that RichAppliance 
dependents upon.
This shall thus enable this form of service decoration
to be portable across containers.
(I am litle-out-of sync with features of Fortress and
Phoenix as to whether this sort of service
enhancements can be acheived in either of the
containers. 
Comments?
)


> Conclusion - put the idea into the wiki and lets
> revisit it after we 
> gain more experience.
> 
Okie.

Regards,
Vinay


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

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


Mime
View raw message