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

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message