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
>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).
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
