Re: semantic conflict

[Leo Simons <le...@apache.org>]

have been thinking about this a lot. Still no obvious conclusion.

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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org