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. -- Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
