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.
runtime values, I understand.
services much less, since it's a service -> Servicemanager...
>> 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
It seems that this is the issue.
If we want to be portable between containers, this just won't work.
IMO *no* container should *ever* be the only one capable of giving that
service.
>> 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.
;-)
> 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).
Yes, this is another misuse IMHO.
Context is a very delicate point in the context ;-) of component
portability.
Personally I tend to think (sensation) that the whole concept of Context
is flawed, because it is usually used in the wrong way.
Services can be given by the ServiceManager. The container should
*never* expose itself to the components it manages, it breaks SoC and
IoC. This means that the abuve services you mention should not be given
at all to the component, given as a service or given in a standard way
that we should define.
I think that Context is a hole in the whole architectire.
What cases can *only* be /reasonably/ solved by a Context?
How can we try to enforce good use of it?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
