avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Murdoch <adammurd...@apache.org>
Subject Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Date Tue, 03 Dec 2002 10:16:34 GMT
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".

> That
> 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.

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.


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