avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: KISS (was Re: [RT] semantic conflict - poolable)
Date Fri, 17 Oct 2003 21:45:15 GMT


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:mcconnell@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message