Nicola Ken Barozzi wrote:
>
> 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...
Agreed.
>
>
>>> 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.
This is an important point. If a container is providing a service -
then it must be declared as a dependecy by the component that it using
it. Without that it will not be possible to validate a components
integrity before lifecycle processing.
>
>
>>> 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.
Please don't assume that the above statement from Pete is based on fact.
>
> 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.
This is the issue - "given as a service or given in a standard way that
we should define" - we know how to create components - we have to define
the standard way of creating context.
>
>
> I think that Context is a hole in the whole architectire.
>
> What cases can *only* be /reasonably/ solved by a Context?
String name = (String) context.get("name");
File rootDir = (File) context.get("root");
ClassLoader loader = (ClassLoader) context.get("classloader");
>
> How can we try to enforce good use of it?
By providing a specification of how context values can be created. That
specification then defines the limitation a developer can work within to
ensure component context usage is not tied to a particular container.
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]>
