> -----Original Message-----
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, 13 February, 2002 17:17
> To: Avalon Developers List
> Subject: Re: [VOTE] RE: ComponentManager interface
>
>
> Stephen McConnell wrote:
> > Berin:
> >
> > Paul's vote on the ComponentManager interface proposal brings
> > the number of +1 votes to 3, sufficient to go ahead with the
> > ServiceManager proposal. Your reply on the initial request for
> > vote was somewhat unclear with respect your position. If I
> > understand correctly, you stated that in principal you would
> > be -1 on anything not linked to Avalon 5.0. As the proposal
> > is not linked to Avalon 5.0, can you clarify for me if your
> > message should be counted as a veto. If not, I'll go ahead
> > a commit the proposed service package this afternoon.
> >
> > Cheers, Steve.
>
>
> :/
>
> I thought you could tell due to the fact that I was presenting the
> Resolver package as an alternative that I haven't moved to +1 yet.
:-)
I had a sneaking suspicion that maybe you weren't quite at a +1!
> I want to eventually add in a Query object ability--so we have two
> options.
>
> 1) The ServiceManager stays as is with the change that the key lookup
> is an Object instead of String (String is common case, but allows
> for Query object enhancement later).
>
> 2) The ServiceManager has two methods: one String, and one Query object
>
>
> Due to all the feedback, the Query object would be simplified to one
> key and attributes.
>
> Another alternative to the whole explicit Query object is the following:
>
> interface ServiceManager
> {
> Object lookup( String role );
> Object lookup( String role, Parameters attributes );
> void release( Object component );
> }
Of the above options I think the interface described immediately
above makes the most sense. Its consistent with the CM/SM model
and the DefaultServiceManager can basically ignore the Parameters
argument, however, it does provide the basis on which an
implementation can do some serious resolution.
> This way, we can reasonably handle default Lookup, and have no need for
> the ComponentSelector equivalent.
Agreed.
> My observations of the current CM/CS is that in a perfect world,
> we would only need the CM. However, due to the complexities of the real
> world, we need to address a specific configuration of a Component. The
> ComponentSelector was introduced to satisfy that goal. However it is
> terribly clumsy to have to do two levels of lookup.
>
> Please post your thoughts.
Using the above interface things remain open as to what so of object
is returned - so it would be posssible for the container to do quite
interesting things concerning service/component preparation in the
knowlege that lookups can be parameterised. So, yep, I like it.
> If we introduce this change, we won't be able to add the extra
> functionality later for the Query object.
However, you could do something like the following:
public class DefaultQuery extends Parameters implements Query
Cheers, Steve.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
