Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
Subject: Re: [RT] New Lookup mechanism
From: Bruno Dumon <bruno@outerthought.org>
To: Avalon Developers List <dev@avalon.apache.org>
In-Reply-To: <407C145C.8050206@apache.org>
References: <OF231C6038.0AB6A3C8-ONC1256E74.004F4FDE@sundn.de>
	 <1081870633.1393.30.camel@bellagio>  <407C145C.8050206@apache.org>
Content-Type: text/plain
Organization: Outerthought
Message-Id: <1081964649.3259.1753.camel@123.13 	yum.ot 	yum
Mime-Version: 1.0
Date: Wed, 14 Apr 2004 19:44:10 +0200
Content-Transfer-Encoding: 7bit

On Tue, 2004-04-13 at 18:25, Stephen McConnell wrote:
> Hi Marcus!
> 
> I've got some general questions about selection that perhaps you or 
> other could fill me in on.  First off - I'm separating out in my head 
> three different things:
> 
>     1. the interface we use for locating something (lets call
>        it Locator for the purpose of discussion)
>     2. the interface used to supply and instance of a Locator
>        to a component
>     3. the sort of information that a component can include
>        in a locate request and the expected behavior of
>        container in resolving such a request
> 
> Item (3) is the thing that IMO needs to be expanded on.  Here is a 
> couple of examples of an invocation followed by a couple of questions. 
> Please not that I'm also not really worried about the argument or 
> signatures just yet - so don't pay any attention to the approach - I'm 
> in information gathering stage!
> 
>    public void someDeliveryMethod( Locator locator )
>    {
>         Map map = new Hashtable();
>         map.put( "color", "red" );
>         Football football = locator.locate( Football.class, map );
>    }
> 
> In the above the component implementation has to assume that a container 
> has been configured such that "color" is understood - i.e. is 
> translatable to something that will help in the determination of the 
> appropriate instance to be returned.
> 
> Possible interpretations:
> 
>    1. color is an attribute of a component type
>    2. colour is an attribute of a service implemented by a
>       a component type

isn't the service already identified uniquely by the interface?

>    3. color is a feature attributed to a component model
>       (i.e. component model x has configuration y and is
>       tagged with attribute color=red)

yes

I think this also comes closest to what selectors offer, which allow the
same implementation class with different configurations to be assigned
different (excuse the word) hints.

>    4. color is an attribute used by a selection handler
>       that knows about the Football class

Maybe, but this requires extra work.

> 
> Some questions:
> 
>    1. if color is understood by a container, but no solution
>       are resolvable - is that a failure or is the container
>       obliged to return at least some football

failure

> 
>    2. which leads to the question .. should we be describing
>       a Query object instead of a map? E.g.
> 
>         Constraint color = new Constraint( "color" );
>         color.setRequired();
>         color.setValue( "red" );
>         locator.locate( Football.class, new Query[]{ color } );

don't know.

As Carsten pointed out, it might well be that a simple key assigned to a
component model is all we need. Until know, I haven't encountered the
need for more complex queries yet (but also hadn't thought about the
possibility).

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


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