On 02/04/2014 09:55 AM, Eduardo Martins wrote:I’m ok with this, but a few comments inline:
On 04 Feb 2014, at 13:39, David M. Lloyd <david.lloyd@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
theseglobally 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?
Only the components which are globally bound would be visible if there
was no component context. In cases like the one you mention, if a
component's binding is expected to be present, then the component
context must be active at that time. If it cannot be active, then we
cannot support reading component-created bindings - end of story. There
is not a third side to this coin. :-)
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.
Might as well wish that rain falls upwards. The spec is the spec; we
need to support the behaviors that are specified. No real room for
argument here either.
* 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.
Possibly. We can visit that issue if/when it comes up.
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 :-)
Nothing is wrong with java:global. But do not get confused between
"what the user should do" and "what we are expected to support". I'm
speaking strictly to the latter. In that context, it doesn't help to
enter the former into the argument.