> From: Leo Sutic [mailto:[EMAIL PROTECTED]] > > 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
