avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <mcconn...@apache.org>
Subject RE: [VOTE] RE: ComponentManager interface
Date Fri, 15 Feb 2002 06:52:32 GMT


See notes in-line.

> -----Original Message-----
> From: Antti Koivunen [mailto:anryoshi@users.sourceforge.net]
> Sent: Friday, 15 February, 2002 07:00
> To: Avalon Developers List
> Subject: Re: [VOTE] RE: ComponentManager interface
> Stephen McConnell wrote:
> >
> > I thought long and hard about the issues you have raised above.  My
> > decision to separate was driven on the grounds that an implementation
> > can easily apply these patterns and default implementation.
> For example,
> > in your case above .. it easy to define what you need by doing something
> > like the following (ignoring exception management):
> >
> >     interface ServiceResolver extends ServiceManager
> >     {
> >         Object lookup( String role, Object policy );
> >         boolean hasService( String role, Object policy );
> >     }
> >
> >     public class DefaultServiceResolver extends DefaultServiceManager
> >     {
> >         Object lookup( String role, Object policy )
> >         {
> >             ((ServiceSelector)super.lookup( role )).select( policy );
> >         }
> >
> >         boolean hasService( String role, Object policy )
> >         {
> >             ((ServiceSelector)super.lookup( role )).hasService(
> policy );
> >         }
> >     }
> Right, this might be a better approach.

I'll take that as meaning "Right, that IS a better approach." and
proceed on the grounds that we can look at this once the core stuff is

> >>>  interface ServicePool
> >>>  {
> >>>      Object checkout( Object token );
> >>>      Object checkout( Object token, Object criteria );
> >>>      void release( Object object );
> >>>      void releaseAll( Object token );
> >>>  }
> >>>
> >>You have nicely encapsulated the issue of "checkout/release", as it
> >>clearly is a separate concern. However, it shouldn't be a concern of the
> >>client. IMO, the client should be able to access different services in a
> >>consistent way and not worry about whether certain instance is actually
> >>pooled. This approach would require changes in the client code, when you
> >>switch to a poolable service implementation.
> >>
> >
> > I'm not convinced that it isn't a client concern.  The contract between
> > the client and the provider of the service is that it is the clients
> > responsibility to check something back in.  Ok, I understand
> > that it is more convenient in a highly pooled environment for arbitrary
> > release - but I don't find this a convincing argument in terms of the
> > functionality of the framework.  The reason why is that if you declare
> > release on ServiceManager, you are implying that an implementation may
> > support this ([and] generally speaking "may" is a very bad word).
> I see your point and of course agree on the "may" argument, but I still
> feel that the client shouldn't have to know whether the service instance
> is pooled.

This is a good argument. But there are implications on interface clarity
and consequence of the framework implementations that I don't like.  If
you declare an interface which is agnostic relative to the provisioning
policy, then you force modification of the lookup operation to include
a token argument (because an pooled implementation needs the token). This
compremises the interface for ServiceManager beyond the "comfort zone".

> What if there are many implementations for the same role, and
> only some them are poolable. Shouldn't it be possible to switch the
> implementation without changing the client code?

I agree completely with the scenario objective. I don't think the
consequences of the convenience support are justified. An implementation
of ServiceManger that supported "release" on the grounds that it is
auto-magically handling recycled components would require something like
a foralll embedded pools and selectors - release this object if you have
a reference to it.  Given a choice between forcing clients to take
responsibility for knowing for service procurement source type, as
opposed to generic simplification at the framework level, in this
particular case my preference is to push this burden onto the client for
the sake of framework integrity.

> It would of course be possible to use 'dummy pools' for the thread-safe
> services to avoid this, or some kind of a PoolAwareServiceManagerProxy,
> but I'm not confident that it's the right approach.

Implementation side of this "fluffy" outside of an application context
in which you know what your doing.


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

View raw message