ClassNotFoundException when using custom SSLSocket

问题:

I have created a custom SSLSocketFactory class and set it as below

ldapEnv.put(Context.SECURITY_PROTOCOL, "ssl");
ldapEnv.put(FACTORY_SOCKET, socketFactoryClass);

LdapContext ldapContext = new InitialLdapContext(ldapEnv, null);

It works fine when running from Eclipse Dev Environment, and running it as Jar file from command prompt. But it doesn't work when I wrap it inside a service wrapper and launch it as Windows Service. I get the following exception,

javax.naming.CommunicationException: 192.168.100.22:636 [Root exception is java.lang.ClassNotFoundException: com/testing/diraccess/service/ActiveDirectory$TestSSLFactory]
at com.sun.jndi.ldap.Connection.<init>(Unknown Source)
at com.sun.jndi.ldap.LdapClient.<init>(Unknown Source)
at com.sun.jndi.ldap.LdapClient.getInstance(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.connect(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.<init>(Unknown Source)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(Unknown Source)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(Unknown Source)
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(Unknown Source)
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(Unknown Source)
at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
at javax.naming.InitialContext.init(Unknown Source)
at javax.naming.ldap.InitialLdapContext.<init>(Unknown Source)

Caused by: java.lang.ClassNotFoundException: com/testing/diraccess/service/ActiveDirectory$TestSSLFactory
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at com.sun.jndi.ldap.VersionHelper12.loadClass(Unknown Source)
at com.sun.jndi.ldap.Connection.createSocket(Unknown Source)
... 35 more

Any help ???

回答1:

Seems this issue could be due to JNDI's dependence on setting the correct thread context classloader (which admin might not be doing), this is required because JNDI classes are loaded by a class loader at the base of the loader heirarchy and that classloader will not find the classes loaded by application/container class loader. So JNDI provides a hook to load such classes via the thread context class loader.

See if this works,

 // Save the current thread context class loader
 ClassLoader currentCL = Thread.currentThread().getContextClassLoader();

// Set the context class loader to the one we know for sure loaded classes inside configstore-core.jar
Thread.currentThread().setContextClassLoader(OmParticipant.class.getClassLoader());

// Invoke the jndi related code that will internally try to load our socket factory impl
...

//restore the original class loader
Thread.currentThread().setContextClassLoader(currentCL );

回答2:

It's been a very long time since I posted this question. Since this post doesn't have any answers and also seems to be getting some views, I thought I could share what I did then to resolve it finally (I had already posted this in comments section of the question years ago).

I was able to resolve this issue by including that jar file in boot loader class path using -Xbootclasspath/a: option. But I didn't like this solution anyway.