Проблема с вызовом веб-службы из службы JBOSS EJB

У меня есть простая веб-служба, которая находится в нашей внутренней сети. Я использовал SOAPUI для небольшого тестирования, сгенерировал классы обслуживания из WSDL и написал некоторый Java-код для доступа к службе. Все прошло так, как ожидалось, так как я смог создать классы прокси службы и совершать звонки. Довольно простые вещи. Единственный скачок скорости - это заставить Java доверять сертификату с машины, предоставляющей веб-сервис. Это была не техническая проблема, а скорее отсутствие у меня опыта работы с веб-службами на основе SSL. Теперь о моей проблеме. Я закодировал простую службу EJB и развернул ее на сервере приложений JBoss 4.3 и теперь получил следующую ошибку в коде, который ранее работал.

12:21:50,235 WARN  [ServiceDelegateImpl] Cannot access wsdlURL: https://WS-Test/TestService/v2/TestService?wsdl

Я могу получить доступ к файлу wsdl из веб-браузера, запущенного на том же компьютере, что и сервер приложений, используя URL-адрес в сообщении об ошибке. Я также могу запустить код, который обращается к веб-сервису вне сервера приложений, на том же компьютере, что и сервер приложений (но не изнутри). Я не понимаю, куда идти дальше. Я включил журналы отладки в JBOSS и не получил ничего, кроме того, что показал выше. Я поискал в сети и обнаружил ту же ошибку в некоторых вопросах, но на эти вопросы не было ответов. Классы веб-сервисов были созданы с помощью JAX-WS 2.2 с использованием задачи wsimport ant и помещены в jar-файл, включенный в пакет ejb. JBoss развернут в RHEL 5.4. Я разместил это на форуме сообщества JBOSS, но на момент написания не получил никаких ответов.


java jboss jax-ws
person Rob Goodwin    schedule 11.05.2010    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Взглянув на ServiceDelegateImpl, он пытается сделать:

InputStream = wsdlURL.openStream ();

где wsdlURL - ненулевое значение URL. Значит, проблема в openStream(). Я предполагаю, что проблема связана с корневым сертификатом https; Я могу представить, что у JBoss где-то есть собственное хранилище приемлемых корневых сертификатов, и что вашего корня там нет.

Чтобы проверить это, я бы развернул службу на HTTP-сервере и сделал wsdlURL http URL-адресом. Если это сработает, то это уровень SSL.

Если это уровень SSL, попробуйте вручную добавить хранилище ключей, указав его в командной строке, как в ответе на этот вопрос SO.

person extraneon    schedule 18.05.2010
comment
Спасибо за предложение. Я попытаюсь развернуть службу через HTTP, чтобы исключить уровень SSL в JBoss. Я начал запускать сервер и свой тестовый клиент в подробном режиме, чтобы увидеть, могу ли я увидеть разницу в загружаемых классах / банках, но это кажется более логичным местом для поиска. Отчитаюсь. Еще раз спасибо - person Rob Goodwin; 18.05.2010
comment
Да ошибка в том, что JBoss не доверяет машине веб-сервисов. JBoss проглатывает исключение, которое устраняет проблему. При попытке открыть поток, как вы указали выше, возникает следующее исключение. javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: сбой построения пути PKIX: sun.security.provider.certpath.SunCertPathBuilderException: невозможно найти действительный путь сертификации для запрошенной цели Итак, как только я выясню, как правильно получить Сервер JBoss доверяет сертификату сервера веб-сервисов, я опубликую его и помечу как ответ - person Rob Goodwin; 20.05.2010
comment
@Rob Goodwin Вопрос SO, на который я ссылался, должен быть в состоянии ответить на это. В принципе, вы можете импортировать доверенные корневые сертификаты в это хранилище ключей для использования JBoss. Конечно, вы также можете переключить реализацию валидатора SSL и спроектировать его так, чтобы он вообще принимал что угодно, но это своего рода взлом :) - person extraneon; 20.05.2010
comment
Проблема заключалась в том, что, как вы и ожидали, JBoss использовал собственное хранилище сертификатов (ключ и доверие). Поэтому я указал его в командной строке –Djavax.net… но не знал, что это было заменено в каком-то другом нестандартном месте другим сценарием запуска. Но с помощью строки -Djavax.net.debug = ssl в предложенной вами ссылке хранилище ключей, которое оно использовало, было зарегистрировано. Простая команда find / grep, и мне удалось найти скрипт, вызывающий нарушение. Я добавил сертификат сервера веб-службы, которую хотел вызвать в это хранилище ключей, и теперь все готово - спасибо за ваше предложение. - person Rob Goodwin; 21.05.2010
comment
@ Роб Гудвин Рад слышать, что вы решили проблему. Эти вещи найти нелегко :) Приветствую grep -r -H! - person extraneon; 21.05.2010