At 07:23 PM 7/3/2002 +0000, you wrote:
>Trying to follow what's going on here it seems to me that Stephen wants
>an ObjectConfiguration under the name Context. To me a context is a
>frame of reference -- a description of how the world stands at an exact
>point in time.
agreed.
>Since I've only been thinking of components as services which are
>configured and then utilized I can only see a limited case where being
>able to contextualize a component would make any sense. If a component
>is single-threaded then the following lifecycle would make sense to me:
>
> lookup
> setContext (recontextualizing)
> myMethod
> release
That contextuializes with respect to the request. In this case it is much
better to pass in context to method call. What we are discussin is
contextualization with reespect to the container. ie What features is
container capable of giving to component. ie Everything you are likey to
find in EJBs COntexts (ie EntityContext and friends), ServletContext,
AppletContext etc with the exception of;
* Logging (provided by LogEnabled)
* Configuration (provided by Parameterizable/Configuration)
* directory service + thus services from peer components (which is provided
by Composable)
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]>
