> From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>
> > From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> >
> > Where does the policy object in PooledSelector come from when a
> > lookup is done through a ServiceResolver? Isn't it necessary to have:
> >
> > interface ServiceResolver extends ServiceManager
> > {
> > Object lookup( String role );
> > Object lookup( Object token, String role );
> >
> > Object lookup( String role, Object policy );
> > Object lookup( Object token, String role, Object policy );
> >
> > void release( Object object );
> > void releaseAll( Object token );
> > }
> >
> > where the policy object is passed along to the selector if present?
>
> This principal is that selection (brought about by the introduction
> of a policy argument) is something that can be isolated under a separate
> ServiceSelector implementation. This means that the common ServiceManager
> does not need to be polluted with selection semantics. From an
> implementation perspective this is a really good thing because we achieve
> isolation the behaviour (no empty methods). A selector implementation can
> then apply local policy combined with supplied policy to do the selection
> of an appropriate service. The principal is the you "lookup" the
> directory
> then apply "select" against the directory that is returned.
OK. So in the cases where a lookup returns a ServiceSelector
(and not a PoolableSelector), you get a ServiceSelector back, much like you
get a ComponentSelector back in the current Avalon framework?
I am quite tempted by Berin's Query object approach to this, as well
as letting the ServiceResolver do the lookup + select in one step.
Rationale for this is:
- When you lookup a service through the lookup method,
you return it through the release method.
- When looking up through a selector, you get the service from
the selector, but return it via the resolver.
Allowing the ServiceResolver to accept the key for the selector
would make it easier - you return stuff to the thing you got it
from. Plus, you get a more unified interface. All lookups,
through pools or n-dimensional selectors, are done through
a single interface.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
