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 Wed, 23 Jul 2003 10:03:54 GMT
--- "Farr, Aaron" <Aaron.Farr@am.sony.com> wrote:
> Because DeploymentStageExtensions can access the
> Appliance (and consequently
> the component's configuration), either approach
> works.  

I went along the lines of writing a custom appliance
since I wanted to play around with merlin models.
This route or one that you took of writing 
StageExtensions since they can access merlin 
appliance, are both *merlin* specific
implementations.

As Steve mentioned earlier on this
issue(or atleast the way I interpreted it as) is 
to actually pass a decoration specific descriptor to
its handler in totally avalon compliant fashion.
Thus instead of hooking into the container specific
means to provide decorations to service exports or
access one can merely weave the decorator as a
dependency and pass a decorator specific configuration
to the decorator to enrich the requesting component.

Thus if you take my example(its okie if you dont 
recollect it) :
I had an usecase of auto-magically exporting/exposing
services from a component to non-avalon
consumers(altrmi).
To acheive this I had used custom service attributes+
custom *merlin* appliance to enable the appliance
to hook into the *type* and thus take control of
exporting/exposing the service from the type's
custom service descriptors.
On further deliberation ,bcoz of suggestion from Steve
& others,
I thought it shall be wise to weave this in a totally
*portable* fashion by writing a separate descriptor
(like SomeComponent.altrmi) and write a *pure*
Avalon component which basically handles service
decoration.
Thus, I shall have a SomeComponent.xinfo declaring
a dependency on a  ExtensionPoint( Seems like I am 
seeing a lot of eclipse  nowdays) provider ,
the concrete provider (CompositeExtensionPoint)
of which shall have a list if ExtensionPoint's 
registered to it through its <configuration/>.
(This shall thus be configurable without
jar&un-jarring as you spoke)

Thus during initialization stage of the SomeComponent
I shall 
merely use ExtensionPoint to decorate the 
component.

Thus one can envision something like:- 

interface ExtensionPoint
{
  decorate(Object obj);
}

CompositeExtensionPoint implements
ExtensionPoint,Configurable
{
    //confioguiration would contains a list of
    //decorators 
}

AltrmiExtensionPoint implements ExtensionPoint
{
 public void decorate(Object obj)
 {
    //get the descriptor
    String
resource=obj.getClass().getName()+".xaltrmi";
    //read the resource as configuration and then
    //take action based on it.
    // In this case publish the service on
AltrmiServer
 }


Hope this makes sense.
Thoughts/Comments?

Basic idea is to derive at a means to provide
extension or enhancements to infrastructure which
expecting tooo much from  the container(hehe! :-)) ) .
(Although I hope these forms of common features 
shall be part of the container sometime )



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