ClassNotFoundException при использовании настраиваемого SSLSocketFactory

Я создал собственный класс SSLSocketFactory и установил его как ниже

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

LdapContext ldapContext = new InitialLdapContext(ldapEnv, null);

Он отлично работает при запуске из среды Eclipse Dev и запускает его как файл Jar из командной строки. Но это не работает, когда я обертываю его в оболочку службы и запускаю ее как службу Windows. Я получаю следующее исключение:

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

Любая помощь???

Ответ 1

Прошло очень много времени с тех пор, как я опубликовал этот вопрос. Поскольку у этого сообщения нет ответов и, похоже, есть некоторые взгляды, я думал, что смогу поделиться тем, что я сделал, чтобы наконец разрешить его (я уже опубликовал это в разделе комментариев вопроса много лет назад).

Мне удалось решить эту проблему, включив этот файл jar в путь класса загрузчика, используя опцию -Xbootclasspath/a:. Но мне все равно не понравилось это решение.

Ответ 2

Похоже, что эта проблема может быть вызвана зависимостью JNDI от установки правильного загрузчика классов потоков (который может не выполняться администратором), это необходимо, потому что классы JNDI загружаются загрузчиком классов в базе иерархии загрузчика и этот загрузчик классов не будут найдены классы, загруженные загрузчиком класса приложения/контейнера. Таким образом, JNDI обеспечивает загрузку таких классов с помощью загрузчика классов контекста потока.

Посмотрите, работает ли это,

 // 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 );