For a while now the following issue has been bouncing around, I think it is fair to say it is not going away ;-) : - javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when creating MBeanServerConnection https://issues.jboss.org/browse/WFLY-794 As I have been working on some LDAP features I agreed to look into an LDAP issue from within a deployment and now have raised this issue: - LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given https://issues.jboss.org/browse/WFLY-2319 Both of these issue share a common cause, the following default InitialContext method is not reaching the point where schemes are checked: - protected Context getURLOrDefaultInitCtx(String name) throws NamingException { if (NamingManager.hasInitialContextFactoryBuilder()) { return getDefaultInitCtx(); } String scheme = getURLScheme(name); if (scheme != null) { Context ctx = NamingManager.getURLContext(scheme, myProps); if (ctx != null) { return ctx; } } return getDefaultInitCtx(); } This is because the Naming subsystem sets the InitialContextFactoryBuilder. So lookups or searches that are in the form of a URL e.g. rmi:// or ldap:// are not being handled by their corresponding URLContext. For the standard JNDI lookups it appears we almost already have support for what we need: - https://github.com/wildfly/wildfly/blob/master/naming/src/main/java/org/j... What we seem to be missing is a registration of the factory for the RMI url context. For LDAP we have nothing yet. When users hit problems in this area it tends to be quite serious for them although overall only a small subset of users are affected by this. I am considering if we want the following as a solution although the purpose of this e-mail is for any additional feedback / ideas. 1 - Enhance the Naming subsystem configuration to allow the definition of the factories for URL based contexts. For most users this would not be used, for those that need it there is a config option - this would also allow for JDK specific class names to be specified in the users config. 2 - Provide an InitialDirContext implementation that also makes use of the configuration from #1. This would be slightly different to what we have already done for naming in general as this would have to be a wrapper always used by InitialContextFactoryBuilder to ensure the URL specific context is used whenever one of it's methods is called. Regards, Darran Lofthouse.