<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;"><p style="font-size: 13px;">Last year I’ve been gathering what are the pain points with our current JNDI and @Resource injection related code, mostly the complaints I’ve noted (meetings, user forum, mail list, etc.) are:</p><ul class="Apple-dash-list"><li>too much code needed to do simple things, such as bind a JNDI entry, and very low code reusage</li><li>Naming related APIs not only easy to misuse, i.e. very error prone, but also promoting multiple ways to do same things</li><li>not as slim or performance as it could and should be</li></ul><div><span style="font-size: 13px;">Also, new functionality is needed/desired, of most relevance:</span></div><ul class="Apple-dash-list"><li>ability to use Naming subsystem configuration to add bindings to the scoped EE namespaces java:comp, java:module and java:app</li><li>access bindings in the scoped EE namespaces even without EE components in context, for instance Persistence Units targeting the default datasource at java:comp/DefaultDatasource</li></ul><div><span style="font-size: 13px;">With all above in mind, I started reworking Naming/EE for WFLY 9, and such work is ready to be presented and reviewed.</span></div><div><span style="font-size: 13px;"><br></span></div><div><font size="2">I created a Wiki page to document the design and APIs, which should later evolve as the definitive guide for WildFly subsystem developers wrt JNDI and @Resource. </font><font size="2">Check it out at </font><a href="https://docs.jboss.org/author/display/WFLY9/WildFly+9+JNDI+Implementation">https://docs.jboss.org/author/display/WFLY9/WildFly+9+JNDI+Implementation<span style="font-size: small;"> </span></a></div><p style="font-size: 13px;">A fully working PoC, which passes our testsuites, is already available at <a href="https://github.com/emmartins/wildfly/tree/wfly9-naming-rework-v3">https://github.com/emmartins/wildfly/tree/wfly9-naming-rework-v3</a></p><div><b style="font-size: 13px;">Possible further design/impl enhancements</b></div><div style="font-size: 13px;"><ul class="Apple-dash-list"><li>Is there really a good reason to not merge all the global naming stores into a single “java:” one, and simplify (a lot) the logic to compute which store is relative to a jndi name?</li><ul><li>java: </li><li>java:jboss</li><li>java:jboss/exported</li><li>java:global</li><li>shared java:comp</li><li>shared java:module</li><li>shared java:app</li></ul></ul><div><ul class="Apple-dash-list"><li>Since there is now a complete java: namespace always present, we could avoid multiple binds of same resource unless asked by spec, or with remote access in mind, e.g. java:jboss/ORB and java:comp/ORB</li></ul></div><ul class="Apple-dash-list"><li>Don’t manage binds made from Context#bind() (JNDI API), the module/app binder would be responsible for both binding and unbinding, as expected elsewhere when using the standard JNDI API. Besides simplifying our writable naming store logic, this would make 3rd party libs usable in WildFly without modifications or exposing special APIs. Note that this applies to global namespaces only, the scoped java:app, java:module and java:comp namespaces are read only when accessed through JNDI API.</li></ul><div><ul class="Apple-dash-list"><li>Remove the unofficial(?) policy that defines jndi names relative to java:, and use only the EE (xml & annotations) standard policy, which defines that all of these are relative to java:comp/env</li></ul><div><div>—E</div></div></div><div><br></div><div>PS: the shared PoC is not completed wrt new API usage, it just includes show cases for each feature.</div></div></body></html>