Stephen McConnell wrote:
a strict framework spec interpretation of poolable is that an object returned to the pool is an object that must be destroyed and that a new object must be instantiated to repopulate the pool. Any other assumption contradicts the framework spec. An extension does not change this conclusion because a pooled lifestyle handler must function predictably independently of n possible extensions invoked during the release phase.
indeed.
(a) pooled objects in framework are broken, or (b) pooled objects cannot be container independent, or (c) a common container side pooled object model is required
IMHO, (c). "Manual pooling" is painful; it results in ugly consumer components and less-than-transparent dependency graphs.
How to resolve this? IMO the key point is to recognize that there is a service dependency assumption that can be declared by a consumer that reflect awareness of pooled semantics.
indeed. Precisely the ugly thing about ServiceManager.release() is that consumer components must call it while being otherwise unaware of any pooling. It is (has always been) ugly.
@avalon.dependency type="Widget" pool-aware="true"
ugly! :D
provider states: I required/do-not-require active release consumer states: I provide/do-not-provide active release container: handles resolution
it would be nice if the consumer part of this functionality could be encapsulated in a utility or (shiver) abstract class of some kind. The ability to (nearly) transparently switch from singletons to pooling (for example) is something that's quite powerful and used to great effect in ecm/fortress applications.
I think the right answer to this though question is yet to be found.
- LSD
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
