avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Corey Jewett <co...@triumphevents.com>
Subject RE: [ISSUE] containerkit
Date Wed, 03 Jul 2002 19:23:38 GMT
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. 

For example HttpRequest as a Servlet parameter. Wherein a specific
request is encapsulated and passed in to a method for processing. It
describes the who (session), what (data), where (path), why (inferred),
when (inferred), and how (method, i.e. GET/POST...).

Perhaps I'm missing the whole point here, but, IMHO, semantically
speaking an ObjectConfiguration is not a Context.

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:

	setContext (recontextualizing)

If this is the case then why would setting a context be relevant to
Avalon at all? The caller would have specific knowledge that the
component supported contexts. The only exception I see would be
automatically recontextualizing a component based on metadata, but that
just seems plain convoluted.


On Tue, 2002-07-02 at 17:30, Leo Sutic wrote:
> Stephen,
> I'm all for your approach - it certainly is better than what we have
> now.
> But I would like to solve the cases where the context entry is either
>  + a value (like a java.io.File) provided by the container
>  + an interface to the container (should be accessed via serviceManager
> probably)
>  + something that changes during runtime (a Recontextualizable
> component) and
>    that has new values depending on runtime parameters completely
> independent
>    of application profile, such as performance data.
> /LS
> --
> To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message