I’m ok with this, but a few comments inline:
On 04 Feb 2014, at 13:39, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
I think we need to look into a small redesign of how we handle
java:comp, java:module, and java:app. The reasoning comes in three parts:
* Various specs require that certain names be bound globally across all
of java:comp.
* Various other specs implicitly expect to be able to query these
globally bound names even if there is no actual component context.
In theory this doesn’t make much sense to me, if that’s the idea in the specs then it
would be preferable to additionally specify an entry in java:global too. For instance,
there was recently a thread about a JPA PU pointing to a java:comp datasource, bound by a
web component, and even if I don’t think that’s a good design the fact is the user idea
was truly to have the web component point the way to the PU, but imagine that instead of a
web component there was multiple EJBs binding different datasources to the same java:comp
name, which one would the PU target?
Anyway I think the Java EE 7 RI has this feature implemented, so in the end users would
benefit from common behaviour, just wished this was better specified.
* Duplicating these bindings uses more resources than are necessary.
I believe we still need the same individual MSC services due to at least resource
injection of component scoped binds, after all, even if there are cases of truly global
java:comp binds, there is always the feature where a component is allowed to override
java:comp binds through XML and @Resource.
Therefore I think we need to make a small change - we should have a
"global" version of the three context-specific namespaces that act as a
sort of fallback if there's no (component|module|app)-specific name
bound at a location. This allows us to do a few things:
* Satisfy the spec issues
* Reduce resource overhead
* Allow globally-configured things in the management config to bind to
component/module/app-specific namespaces
One could ask what’s wrong with java:global :-)
—E