avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Date Wed, 04 Dec 2002 00:24:18 GMT

Adam Murdoch wrote:

>On Tue, 3 Dec 2002 04:05 pm, Stephen McConnell wrote:
>> > Does the component *really* care whether a particular
>> > resource is provided by the container or not provided
>> > by the container? Is this an artificial distinction?
>> > Why is it useful to the component writer to split them?
>>So lets explore something like a shutdown service. Presumably a sutdown
>>service does something along the lines of shutting down a component.
>>Which component? Should the component instance be part of the argument
>>to the service ? No. That will be problematic. In effect, we have a
>>"context" - what the component actually wanted was "give me a handle to
>>the thing that started me up so that I can tell it that I'm done". 
>Or, arguably, "give me the thing that I can tell that I'm done".  I don't 
>think the component cares either way about the "handle to the thing that 
>started me up".
>>request is not a peer request - it's a container request - and that is
>>the distinguishing feature here - it's that fact that the component is
>>responding to a stimulus - the stimulus is the startup service.
>There's no question that some resources will almost always be provided by the 
>container.  A shutdown service is a perfect example.  But why is it useful to 
>expose this fact to the component?  Does it care that a shutdown service is 
>provided by the container?  I don't believe so.  All it cares about is that 
>it is provided with a resource it can notify when it is finished doing 
>whatever it does.

I agree (very strongly) with you that the component should not care 
where the service comes from.  

>Assume that the framework will include some way for the container to deliver 
>arbitrary services to a component, and some cross-container way for the 
>component to describe the services it is expecting.  Given this, is there any 
>*real* benefit to the component writer, of adding a second mechanism for 
>describing and delivering arbitrary container-provided services to the 
>component?  Will the component writer have to write more code, or less code?  
>Write more meta-data or less meta-data?  Will the component be more portable, 
>or less portable?  Is there more documentation to read?  More abstractions to 
>figure out?
>Of course, a shutdown service might not actually be such a good example.  A 
>case could certainly be made that component shutdown should be dealt with as 
>part of the Startable lifecycle thing (phase? step? stage? what's the correct 
>terminology?).  For example, Startable.start() could take as a parameter the 
>resource that the component may use to request that it be stopped.

There is a long thread in the archives on stage/phase.  Based on the 
conclusions reached there ... a phase is something container one or more 
stages. A component lifecycle goes though two phases - startup and 
shutdown.  A startup phase is composed of a series of stages (logging, 
contextualization, initialization etc.).  A particular stage can be 
viewed as a phase - e.g.  Initialization appears as a stage in a startup 
phase, but initialization my be implemented as a phase covering 
extension handler deployment following by final initialization (two 
distinct sub-stages).

Now that made things totally clear didn't it ;-)

Anyway back to the topic.

The requestShutdown is probably a bad example because it is something 
that is directly linked to the service that is managing the lifecycle of 
a component.  That's complicating the general issue of context management.

Instead - if both the Serviceable/Composable model is reconsidered as 
something capable of providing services and data objects from a 
containers computational perspective - we can shift focus to "what is it 
that the component writer wants" and look at context service seperation 
based on a needs as oppposed to container implemetation perspective.

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