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 01:54:02 GMT

Mark Woon wrote:
> Stephen McConnell wrote:
> > I removed the release operation from the ServiceManager interface
> > on the grounds that any container that is properly handling release
> > should be using the ServicePool interface.  You can see evidence of
> > the ambiguity of release in the DefaultComponentManager implementation
> > which is basically empty.
> Doesn't this mean that anything that doesn't implement Poolable 
> will not be released?  

This depends on what your interpretation of "release" is.  A 
ServiceManager implementation can take responsibility of disposal of 
service when it is disposed. Keep in mind that release != dispose.
Release could be used to trigger disposal but it could also be used for
instance recycling which would be handled by a ServicePool 

> If so, I was under the impression that it's the call 
> to release that disposes the component.  Won't this be a problem?

An implementation of ServiceManager can dispose of component when 
it's container disposes of the manager implementation.  The typical 
situation with a ServiceManager is that it will provide non-disposable 
singleton services, factories, or new instances of transient objects. 
In the case of the services it exposes, the manager should be 
responsible for handling service decommissioning (invoking stop, 
dispose, whatever). Clients of the service manager should NOT dispose 
of shared services because these service can be in use across multiple 

If the service is providing transient objects (object that the a 
client is disposing of, then the manager implementation should be
creating new instances of the service in response to the lookup 
operation invocation.  

Keep in mind that we do not need to provide enforcement at the 
framework level (that something for application like Phoenix - dynamic
proxy generation based on the service interface etc.).

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>

View raw message