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 implementation. > 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 clients. 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
