avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [RT] New Lookup mechanism
Date Wed, 14 Apr 2004 09:05:07 GMT
Niclas Hedhman wrote: 
> 
> On Wednesday 14 April 2004 15:40, Carsten Ziegeler wrote:
> 
> > This key should be a simple string,
> > so the above could read:
> > locator.locate(Football.class, "red");
> 
> Forgive me for a naive question;
> 
> What is the difference of the above, from;
> 
> servicemanager.lookup( "red-football" ); or 
> servicemanager.lookup( "/footballs/red" );
> 
How do you know what service "red-football" returns? (Ok, of
course *you* know it), but anyone else seeing the above
lookup might not know it. The usual way of doing this,
has been:
servicemanager.lookup("package.Football/red");
So you use the interface name of the service for the lookup.
As this is errorprone because of typos, the ROLE constant
has been added to most service interfaces, so it
looks like this:
servicemanager.lookup(Football.ROLE + "/red");

But this requires to add this constant to the interface which
is bad.

In addition by passing in the interface class, the container
can check if the correct component (implementing the interface)
is returned etc.

Using custom keys like "red-football" that have no semantic
meaning is imho not so good.


> Or in the case you need someone else to figure it out;
> 
> FootballLocator  fbl = (FootballLocator) sm.lookup( 
> "footballs" ); Football ball = fbl.locate( "red" );
> 
Yes, we already have this approach by using ServiceSelectors
which is way to complicated and leads to ugly rather ugly code.

> 
> I think I don't understand where the Framework needs to be 
> involved, and that is what I am trying to understand...
> 
You can do everything already today without any problems, using
ServiceSelectors etc. But imho these approaches are not elegant
and in no way standardized. Introducing this new locator is
a concrete and clear way.

Carsten


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


Mime
View raw message