On Context (was RE: reduction ad unum)

[Berin Loritsch <bl...@citi-us.com>]

> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> 
> Stephen,
> 
> I would argue against your view that a context is a "sealed
> read-only map" providing data.
> 
> First, the definition is the usual untyped hashmap nightmare
> with all the problems that has.
> 
> Second, this assumes that the lookup method of a single string
> arg is the most convenient method of obtaining context information,
> and I doubt this. Just look at the getResourceAsStream() method.
> It doesn't lend itself to an easy Map-based lookup without
> interpretation of the key.
> 
> Third, I think that there is information items that can not 
> be provided
> by lifecycle extensions - that can, in fact, only be provided 
> by the kernel.
> This info may or may not be accessible via Map semantics.
> 
> Fourth, you do not provide any reason at all for a context. 
> Reading your
> mail, my conclusion would be to dump the Context completely. 
> I think it
> has been shown that everything can be realized as a service, and then
> we would not be limited to constant-value lookup (which is 
> more suitable
> for a Configuration anyway).

My friends, lets look at what a Context is supposed to accomplish
in other component based systems, and then apply it here.

Right now, the best analog of Avalon's Context is a Servlet Context.
A Servlet Context provides a scope of information that is global to
a particular Web App.  That Context is shared between all Servlets
that are part of that Web App.  Its purpose in Avalon would be to
provide the same function for a group of deployed components.

It was introduced primarily for Phoenix, but both Giacomo and I saw
use for it in Servlet environments as well.  Please also notice that
EJBs do not really have a Context (not in the same semantics as in
Servlets or Phoenix).  They use JNDI to bind their global values.

In the end there are many ways to skin a cat.  In many cases, you
will find that you don't want or need to skin a cat.  We need to
define what goes in a Context based on how it is intended or *should*
be used.

I started the process of refactoring Fortress to use the ServiceManager
for what it was intended--esp. since I was mis-using the Context because
when that design decision was made the ServiceManger was not in
existence.  That lead to some people's misperception that I was within
the designed parameters of the Context.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>