9:43 a.m.
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.