avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: [ISSUE] containerkit
Date Tue, 02 Jul 2002 14:05:58 GMT

Peter Donald wrote:

> At 08:04 AM 7/2/2002 +0200, you wrote:
>> What are the constraints that Context needs?
> Runtime values and services provided by container.
>> Let me also be the devil's advocate again: what is Context for?
>> ie is it good practice to do in contextualize(Context context)
>>   MYContext mc = (MYContext) context;
> I prefer this option - for no real good reason except that I find it 
> easier to use.
>> ?
>> Or to do
>>   MYContext mc = context.get(MY_CONTEXT);
> Another option.
>> The latter is done in Cocoon, and has created enourmous confusion to 
>> our users (of course, this is not an Avalon deficiency per se, but it 
>> shows how it has been used).
>> Is it good practice to use Contexts to aquire common services?
> Depends who is supplying the service. If the container is supplying 
> the service and is the only one capable of supplying service then the 
> context is the method via which to expose service. If it is just a 
> common service then it should be supplied to all users via 
> ServiceManager.
> Example services that only container can provide;
> * Modification/Saving of Configuration object
> * Access to ClassLoader hierarchy of app
> * Access to ThreadGroup hierarchy of app
> * Access to various code-based Security policys
> * name of component
> etc

Not so keen on the above approach - seems to me like it is mixing 
service and context.  When something needs a "service" it should go 
though the service manager as a result of a formal dependecy 
declaration.  In you avaove list you include the "name of the component" 
- presumably that would be a java.lang.String (which isn't a component 
and cannot be declared as a dependecy) which would be an appropriate 
value to pass through context.

>> IMHO this is not so good, since it's recreating what Serviceable does.
>> As it seems now, a Context works as a common ServiceManager.
> Right - which is wrong.

Context should not be used as a common services manager - that would 
break the service management model.  

> Stephen also treats it in a similar way except wrt to configuration. 
> ie He places global config values in there and treats it as an 
> alternative mechanism to configure components. Much better to use 
> Configuration objects (or Parameters objects).

Stephen does not do the above!
Stephen is wondering why Pete is saying this instead of addressing the 
real issue.

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