Vinay Chandran wrote:
Inline:
--- Stephen McConnell <[EMAIL PROTECTED]> 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).
Sounds terribly familiar!
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).
Confession - I'm working of stuff that will impact the appliance object model (but I guess you may have figured this out already).
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"/>
zutt - like appliance isn't rich enough already!!
(keeping in mind that this is exactly what I did to handle dynamic components over IIOP)
;-)
</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"/>
The approach I've used on this has been either (a) bundle this into a default configuration under the <classname>.xconfig file, or (b) declare a simple attribute that marks the object as you special type and then just read in a supplimentary resource e.g. <classname>.vinay or whatever. My recommendation would be to go with option (b) - user the type.getClassname() to establish the resource path, add you file type, then read the resource in as a stream then use the configuration builder to build you custom data object. Berin identifed similar requirements and we now have an interface for thihs in the meta-spi package (but I don't know what the status of an implementation is) - anyway - doing it without the service is relatively easy.
</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.
I think there is a valid case for attributes without values (or more specifically, defaulting to null if value is not declared).
Steve.
'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 letsOkie.
revisit it after we gain more experience.
Regards, Vinay
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
