avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: [RT] New Lookup mechanism
Date Wed, 14 Apr 2004 09:28:14 GMT
On Wednesday 14 April 2004 17:05, Carsten Ziegeler wrote:

> 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. 

Well, I am Merlin-user, and I think its solution is fairly elegant;

/**
 * @avalon.dependency key="locator"
 *     type="org.hedhman.niclas.sports.FootballLocator"
 */
public void service( ServiceManager sm )
{
    FootballLocator fbl = (FootballLocator) sm.lookup( "locator" );
      :
}

<snip content="ROLE elaboration" reason="agree" />

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

Merlin will ensure that the returned type in the above is a FootballLocator 
and nothing else - guaranteed.

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

Ok, fair enough, I agree on that...

> > 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.

Ugly? :o) Two lines instead of one? Or is it related to try{}catch{} stuff?

> > 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.

Ok. ServiceSelectors are somewhat different, and that difference is the reason 
why they are (and will remain) deprecated.

I think you are bringing up 2 issues;

1. Use Class as Type, and enforce its use in Framework.
2. Passing of auxillary selection information to the container.

I also assume that you are looking for a way so that for each Type, one can 
define a LocatorHandler (didn't want to use the word Selector, but in 
principle same thing)...

How about something like this?

If the component declare a method "someFunkyName()" which takes a single 
argument which is a subinterface of "Locator", the container is responsible 
to provide an implementation of such Locator type to the component.

public class MyComponent
{

    public void locatorService( FootballLocator fbl )
    {
        Football ball = fbl.locate( "red" );
    }
}

Looks very easy for the component author.
Do you think that would that be of help?

I am fishing around the bush, trying to avoid mixing the concerns, which I 
think the locate( Class, query ) does. The query still have to be passed off 
to someone else (container have no clue what to do with it), so why not 
inject "someone else" to the component?


Niclas
-- 
+---------//-------------------+
|   http://www.bali.ac         |
|  http://niclas.hedhman.org   |
+------//----------------------+

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


Mime
View raw message