Leo Sutic wrote:
Stephen,
I would argue against your view that a context is a "sealed
readonly map" providing data.
Umm, lets just take another look at the interface:
public interface Context
{
/**
* Retrieve an object from Context.
*
* @param key the key into context
* @return the object
* @throws ContextException if object not found. Note that this
* means that either Component is asking for invalid entry
* or the Container is not living up to contract.
*/
Object get( Object key )
throws ContextException;
}
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.
That's not Context - that something peculiar to Phoenix.
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.
I disagree with this - in every scenario you can imagine you can provide the object such that the client can narrow to some interface and subsequently apply some invocation against the interfaces. These are different concerns - the concern of context is providing access to contextual state, the concern of a component after narrowing a returned state member is something completely different. The introduction of suppimentary operations on context mixes these concerns - but as the other Leo said, there are grey areas which are largely related to convinience. I happen to think these grey areas can be elimiated with a formal polcy concerning the handling of sugar coating in a consitent way - and if soemthing cannot be handled in this way, then it shouldn't be in context in the first place.
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).
Your making the assumption that a container can only provide canstant -values in context. I don't agree with assumption. Take for example a container that is providing an activation timestamp, the key-chain of the invoking user, and a classloader. These values will typically be different in every application of contexualize. These values canot be expressed in a configuration, or parameters, or under the Serviceable or Composable interfaces.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
