avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <mcconn...@apache.org>
Subject RE: Son of ComponentManager
Date Sun, 17 Feb 2002 09:12:03 GMT


> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Saturday, 16 February, 2002 19:25
> To: Avalon Developers List
> Subject: RE: Son of ComponentManager
>
>
>
>
> > From: Stephen McConnell [mailto:mcconnell@apache.org]
> >
> > Leo Sutic :
> > [snip]
> >
> > > If SM replaces CM in Avalon5, *all* code written for Avalon4 will
> > > break. Not just in a way that can be solved with a search and
> > > replace, but the code has to be re-engineered to detect poolable
> > > components, or do away with those.
> >
> > If we take ExcaliburComponentManager as an example, we can see that
> > the transitional impact of ServiceManager, ServiceSelector
> > and ServicePool is minimal.  ExcaliburComponetManager is in effect
> > a generalisation of the managed and pooled cases.  The only
> > modification required would be the narrowing of the parent manager
> > to a ServicePool before invoking release.
> >
> >   Current Excalibur release implementation includes:
> >
> >       m_parentManager.release(component);
> >
> >   The SOC introduced in the proposal would result in:
> >
> >       if( m_parentManager instanceof ServicePool )
> >         ((ServicePool)m_parentManager).release(component);
>
> So if I have this code:
>
>      MyService service = (MyService) manager.lookup( "MY-ROLE" );
>
> How do I go from a ThreadSafe MyService to a Pooled version without having
> to change my code to:
>
>      ServicePool pool = (ServicePool) manager.lookup( "MY-POOL" );
>      MyService service = pool.checkout( this );
>      MyService service = pool.checkout( this, myCriteria ); // alternative
>      pool.release( service );
>      pool.releaseAll( this ); // alternative


> As you are going from a one-step lookup for non-pooled components to a
> two-step
> lookup for pooled ones.
>
> Also, how do I go from pooled to threadsafe implementations without having
> to change back?
>

Based on the ServiceManager/ServicePool interfaces as presented in 06099,
I think you would need a higher level abstraction that aggregates the two
concerns.  For example:

  interface ServiceResolver extends ServiceManager, ServicePool {}
  interface Resolvable extends Serviceable
  {
     public void resolve( ServiceResolver resolver );
  }

Now you have something equivalent to the current ComponentManager but
with a clean separation of the underlying concerns of the different the
different service lifecycle semantics.  This would allow you to supply
your new feature as an implementation of ServiceResolver which would
reduce the impact of transitioning between service types.  In fact this
would be relatively friendly towards existing implementation such as the
ExcaliburComponentManager.

Cheers, Steve.


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


Mime
View raw message