Berin Loritsch wrote:
Stephen McConnell wrote:
I agree with what your saying about the pool stuff (examples I used were from excalibur pool, not mpool). Presumably mpool pools still need some level of parameterization which that I need to address within the component meta-data (i.e. Merlin directives for pool creation).
Not really--which is the beauty of it.
None? I mean are you saying that there are no parameterization options?
I don't agreed with the "deployment" == "lifestyle" assumption - but more on that in line.
I'm the one who created the definition for the word, as I am the one who first
used it in Avalon contexts. How can it not be what I defined it to be? Help
me understand how that could work.
Ummm, maybe because the term is put onto the table without sufficient defintion?
:-)
Berin Loritsch wrote:
The terminology that I understand ...
* "lifestyle" is a set of policies controlling component creation and destruction
Hmmm. Lifestyle == deployment strategy. You understand incorrectly.
Deployment and management are two different things. A decision to deploy a new component is something done by a lifestyle handler. The deployment of a new instance is a seperate and distinct concern that requires no "lifestyle" info. I.e. "lifestyle" != deployment strategy, instead - "lifestyle" == management strategy.
* "factory" an object used by a lifestyle implementation to handle new component deployment and decommissioning
Same as the Factory pattern.
* "handler" an implementation of a particular set of lifestyle policies
Correct
* "deployment" - the act of taking a component though its "lifecycle" to an established state
Ok, but that does not address the issue of *strategy*.
I need to expand *strategy* - are you referring to:
* a deployment strategy as in classic Avalon lifecycle versus a servlet lifecycle?
* a management strategy as in pooled verus singleton?
* a stage handling strategy as in a custom contextulization interface?
AFAIAC - *deployment* is the execution of a lifecycle strategy.
* "decommissioning" the action of taking a component from an established state to an un-deployed state
Ok.
* "lifecycle" is a collection or ordered stages
correct.
* "stage" a step in deployment lifecycle that may implemented using a specific strategy
Just drop the phrase "that may implemented using a specific strategy"
and you've got it. THe extra phrase does not add anything relevant to
the definition and it is bad grammer. ("that may BE").
:-)
But a stage *is* implemented using a particular strategy - normally that styrategy is the Avalon classic - but it may be something different.
At the end of the day I think we are in sync. When you using the term lifestyle you thinking "a type of lifestyle handler"- and I'm thinking "a set of lifestyle policies".
I believe I have already stated what I meant when I coined the term.
Comming up with a term does not constitute the establishment of a specification.
;-)
The last thing I am going to say is that the end proposal seems overly
complicated. Let's see here. I want to get this component pooled. What is
the exact combination of options I need here? Or Let's see here. I want to
implement a container. Now what exact combinations would specify pooling,
thread boung components, etc.? It hurts my brain thinking about it.
Its not bad as that. If you want you component to be pooled you do:
@avalon.component lifestyle="pooled"
I.e. no change. Howver, in the mpool and pool packages there are supplimentary marker interfaces (Recyclable, Reclaimable, etc.). This is simply meta-info about the component type and should be expressed in the meta-info package - not in marker interfaces.
Not quite. The interfaces Resettable and Recycleable are *functional*.
They do not merely mark the object. They provide a point for the object
to reset itself to an initial state when we are done with it. Now, I agree
that the interface Poolable is meta information, which is why the MPool
stuff does not have an equivalent to that.
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?
Stephen.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
