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 Tue, 03 Dec 2002 06:05:14 GMT

Peter Donald wrote:

>On Tue, 3 Dec 2002 13:17, Adam Murdoch wrote:
>>Hence my question:  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?
>Essentially it comes down to the context wrt the resources is requested. For 
>example lets consider Logger. Historically we had LogManager as a service 
>that components depended on to get at their logger. So it would look 
>something like;
>class MyComponent
> void service( ServiceManager sm )
> {
>   LoggerManager lm = (LoggerManager)sm.lookup( LoggerManager.ROLE );
>   m_logger = lm.getLogger( "my-channel" );
> }
>In this case you are passing component specific context (ie string 
>"my-channel") into LoggerManager. Now if you wanted two different instances 
>of MyComponent - say one production and one testing - they would both log to 
>the same channel or we would have to create multiple instances of 
>However when the container manages allocation of Logger resource they can be 
>remapped without the Component writer knowing about it or caring. 
>Everything available in the context can either be made into a service or 
>blended into configuration or both. The problem is that when the resource 
>(data or service) requires per-component context you end up having a "fake" 
>provider component per component. So assembly requires mapping of several 
>"fake" components to the dependencies in the "real" components (ie the ones 
>you actually care about). You also end up duplicating data between different 
>stages. ie assembly process names components and links them to resources 
>resources and those same names need to placed in configuration of "fake" 
>provider components.
>You could say that this could all be auotmated with some PFM but when we went 
>this path in the past the users complained about the complexity of assembly 
>process because you have to be aware of the minute details of how the 
>container does the PFM and so you have not made it easier on users unless 
>they are already know everything (which are not the ones who need help 
>When more advanced assembly processes come into play (ie different interceptor 
>chains per component client) you duplicate much more information and add much 
>more magic. Too complex to manage without a tool and I don't think it is in 
>our best interests to require a tool to write applications.

Umm, ... does this answer providing a conclusion to the question ...
I don't think so.

Let's reprint the question:

 > 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?

The issue here concerns expectations that the component author has to 
the services and state it is provided with. The component author does 
not give a diddly-bob about the problems, loops and hurdles a container 
author has to jump though in order to meet the requirements they have - 
they have the requirements - and they are right.

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". 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 is nothing in the framework contract for service or context that 
lets us distinguish between peer versus containment context.

But we can fix this is meta.


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