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: too much code needed to do simple things, such as bind a JNDI entry, and very low code reusage Naming related APIs not only easy to misuse, i.e. very error prone, but also promoting multiple ways to do same things not as slim or performance as it could and should be Also, new functionality is needed/desired, of most relevance: ability to use Naming subsystem configuration to add bindings to the scoped EE namespaces java:comp, java:module and java:app 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 With all above in mind, I started reworking Naming/EE for WFLY 9, and such work is ready to be presented and reviewed. 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. Check it out at https://docs.jboss.org/author/display/WFLY9/WildFly+9+JNDI+Implementation A fully working PoC, which passes our testsuites, is already available at https://github.com/emmartins/wildfly/tree/wfly9-naming-rework-v3 Possible further design/impl enhancements 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? java: java:jboss java:jboss/exported java:global shared java:comp shared java:module shared java:app 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 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. 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 —E PS: the shared PoC is not completed wrt new API usage, it just includes show cases for each feature.