OK- I missed that point. What your saying is that a restable component is one where the container's only participation is to invoke reset - i.e. no decommissioning, recommissioning, etc. The responsibility rests with the component to reset any local state before returning from the method - resulting in the state equivalent to the post-deployment state - following which the container returns the resttable to the pool?
In so many words, yes.
In truth, it is the pool manager that calls the "reset()" or "recycle()"
method. All the container does is call the method, and the component
takes care of the rest.
Huston - we have a problem.
If a component declars that it is "pooled" - this is handled relative to the avalon-meta package in that a lifestyle property is set. However, the notion of reseting a pooled component is not part of avalon-meta or framework.
Understood. Note that the act of "resetting" a component has no effect if the component is not pooled.
Therefore:
A container written to spec which is operating independently of the excalibur-pool or excalibur-event package has to deal with pool re-population in the context of a returned (released) instance. The options open to a container are:
(a) decommission the supplied instance and create a new instance, or (b) recommission the supplied instance
If (and only if) Ressettable was part of the framework contract - you could imagine a third option:
(c) reset the supplied instance
I understand your concerns. Could the component "reset" method be called by an Accessor extension? Absolutely. The Resettable interface applies to generic objects that the PoolManager manages. As far as the PoolManager is concerned, it only works with objects. It doesn't care wether the objects are components or not.
But Resettable is not part of the framework so that option is out of scope (meaning - it is not part of the standard container/component contract and as such its *not* something that a component author can expect a container to respect). However - resettable is an example of a custom Avalon based redeployment strategy. What does this mean with respect to lifestyle manegement? Maybe is means that management covers (a) the decisions as to when new components are created (b) and decisions as to what strategy to apply to a released components (including application of redeployment options).
Remember that pooling is the whole reason we have to release components. So yes, there is some level of understanding of Container requirements to redeploy a used component.
It is also a reason we have Accessor lifecycle extensions. In essence, the Resettable interface can be implemented with the Accessor extension for these components.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
