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:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
