Seekings advise whether it is me/my understanding or some flaw in
Tomcat's class loader hierarchy. The test happens on Tomcat 8.5.54 with
Java 13 for JDK-8160768.
My implementation of javax.naming.ldap.spi.LdapDnsProvider is packed
along with the META-INF/services/javax.naming.ldap.spi.LdapDnsProvider
file into a JAR and deployed to common.loader (CATALINE_HOME/lib).
The library which uses JNDI LDAP is in common.loader too which in turn
is used by a custom realm from common.loader. It creates a new initial
directory context which uses java.util.ServiceLoader to load all
instances of javax.naming.ldap.spi.LdapDnsProvider. But nothing happens,
my instance in not loaded. As soon as I move it out from common.loader
to bin and pass that JAR to CLASSPATH it suddenly works.
From my understanding of Java 9 class loader hierarchies [1],
javax.naming resides in the bootstrap class loader, catalina.jar is in
system class loader and common.loader comes later. From ServiceLoader
Javadoc:
> The provider must be accessible from the same class loader that was
initially queried to locate the configuration file; note that this is
not necessarily the class loader from which the file was actually loaded.
My code uses classes from the bootstrap class loader which uses service
loader to load, but since my provider is in a hierarchy way up, not
system class loader or below, the provider is not visible to it?
Michael
[1] https://stackoverflow.com/a/46494370/696632
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
