> -----Original Message-----
> From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, 17 February, 2002 19:30
> To: Avalon Developers List
> Subject: RE: Son of ComponentManager
>
>
>
>
> > 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?
Yes.
> 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.
This break islolation (which is a fault in the current proposal).
What whould be more correct is that the source of provision is the
source of redemtion. I think that was already raised in antother
thread .. basically ServiceResolver and PooledSelector should
inherit from a common interface enabling redemption - e.g.
ServiceReclaimer.
interface ServiceReclaimer
{
void release( Object object );
void releaseAll( Object token );
}
interface ServiceResolver extends ServiceManager, ServiceReclaimer
{
Object lookup( String role, Object token );
}
interface PooledSelector extends ServiceSelector, ServiceReclaimer
{
Object select( Object token, Object policy );
}
This effectively eliminates the obligation for a service resolver to
know about a selection implementation. The selection implementation
is now free to release service in any way it see fit - potentially
independently of the resolver.
Cheers, Steve.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
