Исключение: java.util.ServiceConfigurationError

У меня была та же проблема с развертыванием шлюза USSD с Mobicents Jain Slee, который работает поверх JBoss AS 5.1.0 GA. Шлюз должен подключаться к серверу через SOAP, поэтому я выбрал JAX-WS и сгенерировал исходный код из WSDL с помощью wsimport. Кстати, я использовал подобную процедуру для этого, чтобы создать дочерний проект Maven и сгенерировать java файлы для JAX-WS.

---

Не удалось выполнить развертывание с зависимостями, встроенными в.war файл

Мой первый подход состоял в том, чтобы включить все зависимости в файле.war, который был развернут в JBoss. Я думаю, что это достигается по умолчанию в Maven, и mvn install сделает это. В конечном итоге этот подход не удался, но по крайней мере мне нужно было узнать список файлов jar, которые были включены в файл.war, чтобы скопировать их позже в каталоге JBoss.

Я сделал много проблем с этим подходом и имел много ошибок журнала, хотя основной из них был следующим:

java.util.ServiceConfigurationError: javax.xml.ws.spi.Provider: Provider org.jboss.ws.core.jaxws.spi.ProviderImpl not a subtype

---

Развертывание без зависимостей

Maven tweak

Таким образом, я добавил <scope>provided</scope> к зависимостям JAX-WS. Что-то вроде:

<dependency>
    <groupId>com.sun.xml.ws</groupId>
    <artifactId>jaxws-rt</artifactId>
    <version>2.2</version>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>com.sun.istack</groupId>
    <artifactId>istack-commons-runtime</artifactId>
    <version>2.2</version>
    <scope>provided</scope>
</dependency>

Это создало гораздо более легкий файл.war.

Скопируйте и удалите банки в JBoss AS

Теперь, после развертывания.war файла, когда мой клиент SOAP попытался подключиться к веб-службе и выбрал исключение:

org.jboss.ws.metadata.wsdl.WSDLException: Invalid default namespace: null
at org.jboss.ws.tools.wsdl.WSDLDefinitionsFactory.parse(WSDLDefinitionsFactory.java:134)
at org.jboss.ws.metadata.umdm.ServiceMetaData.getWsdlDefinitions(ServiceMetaData.java:293)
at org.jboss.ws.metadata.builder.jaxws.JAXWSClientMetaDataBuilder.buildMetaData(JAXWSClientMetaDataBuilder.java:84)
at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.<init>(ServiceDelegateImpl.java:138)
at org.jboss.ws.core.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:63)
at javax.xml.ws.Service.<init>(Service.java:79)
at org.ortelius.UssdServiceImplementation.<init>(UssdServiceImplementation.java:42)
at org.ortelius.OrteliusClient.sendUssdRequestToWs(OrteliusClient.java:28)

Кажется, что javax.xml.ws.Service вызывает org.jboss.ws.core.jaxws.spi.ProviderImpl, но он должен вызывать com.sun.xml.ws.spi.ProviderImpl, так что кажется, что существует конфликт с jar зависимости.

Чтобы избежать этой проблемы, необходимо было:

1. Переместите или удалите все jar файлы JBoss, найденные в $JBOSS_HOME/lib/endorsed/.
2. Скопируйте банки, включенные в мой начальный файл.war (один из неудавшихся развертываний) в $JBOSS_HOME/lib/endorsed/. все банки, вложенные в мой.war файл.

Это в основном сделало это.

---

Итоговые заметки

Должен признаться, что для выяснения этого была настоящая боль, и мне потребовалось около четырех дней, чтобы получить это и запустить. Я сделал много проблем с использованием jar-зависимостей, проверял журналы JBoss, удаленная отладка, сравнивал версии Java-пакетов и классов, искал банки в Интернете и читал много статей из руководств JBoss, блогов, StackOverflow, JavaRanch и т.д.

Клиент SOAP был очень прост, но развертывание в JBoss было довольно проблематичным. Мое решение не очень ортодоксально, так как оно сильно зависит от зависимостей файлов jar. Поэтому я не уверен, что это сработает для всех.

С уважением.