In order to avoid the predetermined "well-known" name situation that you described above. That is exactly why you want local contexts.
...snip ..
With a separation between global and local the code stays independent of this and other namespacing issues anyhow.
Yeah, Ijust wonder how much James really nees it, but I think it may be unavoidable
If you had one EJB looking it up by the "well-known" name on JBoss the same code would fail on WebLogic.
yeah, what I'd propose would be that instead of using "well known" names that the API actually constrains the namespaces which can be used for portability. Frameworks allow development to achieve benefits because they contain pre-determined decisions which suit developments which don't challenge the scope of the framework. I think J2EE missed a trick by omitting to mandate namespaces more thoroughly. After all I struggle to see why anyone would care what the namespace is, so long as it is appropriately granular. Vendor specific deployment descriptors and namespace mappings always look like a kind of fudge, as if sun threw up its hands and said "enough" because there was too much variability in too many parameters. I understand that there needs to be extensibility at the edges to allow a framework to accept new technology and new thinking, and to evolve, and I understand that ther are benefits to vendor specific extensions. What I don't accept is that those requirements necessarily mean that a framework cannot mandate the things which are comfortably in scope.
This is less clear of an analogy here at this point, but supposing there are a number of mailets and services and that in some cases they can be swapped, or in the case of multiple instances with different configuration or location independence, the separation becomes more clearly advantageous.
I agree that if you want to have two provisions of a single service type you need to map a provision to satisfy a dependance. What I'm asking is is that scenario a requirement for this API, or can we reason that it'll be so rare that we can ignore it providing that we don't actually exclude the possibility of satisfying it later? d.
