ClassNotFoundException при использовании пользовательских SSLSocketFactory - PullRequest
Новая
       3

ClassNotFoundException при использовании пользовательских SSLSocketFactory

13 голосов
/ 24 ноября 2011

Я создал собственный класс SSLSocketFactory и установил его следующим образом 

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

LdapContext ldapContext = new InitialLdapContext(ldapEnv, null);

Отлично работает при запуске из среды разработки Eclipse и запуске его в виде файла 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

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

Ответы [ 2 ]

0 голосов
/ 10 марта 2016

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

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

0 голосов
/ 29 июля 2015

Кажется, эта проблема может быть связана с зависимостью 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 );
...