<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 04 Feb 2014, at 16:10, David M. Lloyd <<a href="mailto:david.lloyd@redhat.com">david.lloyd@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On 02/04/2014 09:55 AM, Eduardo Martins wrote:<br><blockquote type="cite">I’m ok with this, but a few comments inline:<br><br>On 04 Feb 2014, at 13:39, David M. Lloyd <<a href="mailto:david.lloyd@redhat.com">david.lloyd@redhat.com</a>><br>wrote:<br><br><blockquote type="cite">I think we need to look into a small redesign of how we handle<br>java:comp, java:module, and java:app. The reasoning comes in<br>three parts:<br><br>* Various specs require that certain names be bound globally<br>across all of java:comp.<br><br>* Various other specs implicitly expect to be able to query<br>theseglobally bound names even if there is no actual<br>component context.<br></blockquote><br>In theory this doesn’t make much sense to me, if that’s the idea in<br>the specs then it would be preferable to additionally specify an<br>entry in java:global too. For instance, there was recently a thread<br>about a JPA PU pointing to a java:comp datasource, bound by a web<br>component, and even if I don’t think that’s a good design the fact<br>is the user idea was truly to have the web component point the way<br>to the PU, but imagine that instead of a web component there was<br>multiple EJBs binding different datasources to the same java:comp<br>name, which one would the PU target?<br></blockquote><br>Only the components which are globally bound would be visible if there<br>was no component context. In cases like the one you mention, if a<br>component's binding is expected to be present, then the component<br>context must be active at that time. If it cannot be active, then we<br>cannot support reading component-created bindings - end of story. There<br>is not a third side to this coin. :-)<br></div></blockquote><div><br></div>Just pointing why I think using java:comp outside of the scope of a component doesn’t “look” good.</div><div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br><blockquote type="cite">Anyway I think the Java EE 7 RI has this feature implemented, so in<br>the end users would benefit from common behaviour, just wished this<br>was better specified.<br></blockquote><br>Might as well wish that rain falls upwards. The spec is the spec; we<br>need to support the behaviors that are specified. No real room for<br>argument here either.<br></div></blockquote><div><br></div><div>Maybe I explained my point badly, what I mean is that if there was the intention for java:comp binds, the ones present in every java:comp, to be accessible out of the scope of a EE component, something that I never found a reference in any spec, then the specs should have defined these binds in java:global instead of java:comp.</div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br><blockquote type="cite"><blockquote type="cite">* Duplicating these bindings uses more resources than are<br>necessary.<br><br></blockquote><br>I believe we still need the same individual MSC services due to at<br>least resource injection of component scoped binds, after all, even<br>if there are cases of truly global java:comp binds, there is always<br>the feature where a component is allowed to override java:comp binds<br>through XML and @Resource.<br></blockquote><br>Possibly. We can visit that issue if/when it comes up.<br></div></blockquote><div><br></div><div>My point is that we won’t save much, if any, resources. Note that right now what we usually have is that the java:comp bind is injected with a java:jboss or java:global object, other than the binder services. And if we need the binder services because of resource injection, to point to particular component’s java:comp naming contexts...</div></div><div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br><blockquote type="cite"><blockquote type="cite">Therefore I think we need to make a small change - we should have a<br>"global" version of the three context-specific namespaces that act<br>as a sort of fallback if there's no (component|module|app)-specific<br>name bound at a location. This allows us to do a few things:<br><br>* Satisfy the spec issues * Reduce resource overhead * Allow<br>globally-configured things in the management config to bind to<br>component/module/app-specific namespaces<br><br></blockquote><br>One could ask what’s wrong with java:global :-)<br></blockquote><br>Nothing is wrong with java:global. But do not get confused between<br>"what the user should do" and "what we are expected to support". I'm<br>speaking strictly to the latter. In that context, it doesn't help to<br>enter the former into the argument.<br></div></blockquote><div><br></div>But we already satisfy the specs, there is no spec, or even TCK test, that shows otherwise…</div><div><br></div><div>Anyway, I said I’m ok with all of this, just wanted to expressed my concerns, and if no one else has these too, then let’s move on and kick off the action.</div><div><br></div><div>—E<br></div></body></html>