3:07 p.m.
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.