avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Extensible Lifecycle Requirements
Date Tue, 06 Aug 2002 02:46:40 GMT

Berin Loritsch wrote:

>>From: Stephen McConnell [mailto:mcconnell@apache.org] 
>>Berin Loritsch wrote:
>>>Which is 180 degrees from what terminology already existed.
>>Before making a decision on this I checked through the Fortress 
>>documentation and javadoc and basically found occurances of 
>>phase in one place and stage in another when refering to the 
>>same subject. 
>This is an error in the documentation.  Can you point me to where it

If I come across something I'll drop you an email off-line - if your 
really worried about it try crawling the javadoc in the sources and the 
code documentation for the lifecycle stuff usage in Fortress (but just 
between me and you - I think this is a storm in a tea cup and not worth 
the effort - documentation in Fortress lifecycle stuff is consistent and 
makes sence - documentation in Merlin is consitent and makes sence - 
Merlin distinguish phases from stages at the API which does not occur in 

>>Consulting dictionaries on the topic was not a absolute source of 
>>clarification, however - I settled on "phase" and "stage" on 
>>the grounds 
>>of the following definition from the Merriaum Websters dictionary:
>>  STAGE:
>>  - a period or step in a progress, activity, or development;
>>    especially : one of the distinguishable periods of growth and
>>    development of a plant or animal b : one passing through a
>>    (specified) stage
>hense the defined steps by the interfaces.

Sorry - disagree.  

To me a stage implies something ordered ("stage 1 completed, commencing 
stage 2").

Given a lifecycle interface (e.g. Exploitable) - in isolaltion you don't 
have any idea about its ordering to other lifecycle interfaces - given a 
interface handler, you do have information about the interaction points 
that the handler needs to participate in - but no informaiton about its 
ordering with respect to other handlers.  The interaction points are the 
well know stages in the component management process.  These stages are 
immutable and ordered (CREATE, ACCESS, RELEASE, DESTRORY).  Its not 
until you get to the type defintion that you start to see anything 
related to sequencing of a lifecycle extension handler, and even then 
its independent of the handler.  The only thing you can say about an 
extension and its handler is that it introduce a difference in behaviour 
from the norm (which seems really consistent with the Webster defintion 
of phase).

>>  PHASE:
>>  - an individual or subgroup distinguishably different in appearance
>>    or behavior from the norm of the group to which it belongs
>Meaning a group of steps, or stages.

Sorry - I really don't get the translation you have supplied.  
The Webster defintion talks about "an individual or subgroup 
distinguishably different" and your translating that to mean "group of 
steps, or stages" .... ummm?  Bottom line - when we are talking about 
lifecyle phases, stages, steps, I think we all understand what we are 
talking about.  When we are talking about component management stages we 
tend to qualify what we are talking about so its clear to the audience - 
I will use the word stage when I'm taking about something that is well 
known, probably has a specific order in a sequence.  I will use the 
phase when talking about soemthing more abstract.  Let's not get hung up 
on this. When I'm thinking about lifecycle extensions in the abstract 
they will conceptual phases - when I apply that phase I may want to 
refer to it as a stage becuase I have placed it in a context with order, 
sequence, etc. When a developer creates a lifecycle extension they don't 
have notions of sequence or order of application - as such they are 
building something which will represent a phase in the lifecycle of a 
component. The developer does know about some specific component 
management lifecycle stages that represent interaction points between a 
container, itself and a target component.  As such, the term stage  is 
correctly used here - its referencing well-know ordered entry points 
defined by a container. When a developer build a type with lifecycle 
extension depedencies, they are still talking in terms of phases because 
they are not in control of the big picture.  The developer can say - "I 
need a handler for this phase".  When we get into the actual execution 
of this stuff - the container can take extensions, map them to phase 
handler depedencies, and apply these handlers at the specific stages it 
is controlling in the component management lifecycle.  

Cheers, Steve.


Stephen J. McConnell

digital products for a global economy

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

View raw message