Maven Использование JAX-WS 2.1 Вместо JAX-WS 2.2

Я использую Netbeans 7 с Maven 2.2.1 и jaxws-maven-plugin 1.12. Код развернут на Glassfish 3.1 - или будет, когда я его скомпилирую:)

Когда я создаю проект, wsimport работает как ожидалось и генерирует исходные файлы из предоставленного WSDL. Проблема состоит в том, что сборка не выполняется на этапе компиляции со следующими тремя исключениями. Исследуя это, я вижу, что эти конструкторы были добавлены из JAX-WS 2.1 в JAX-WS 2.2. Я убежден, что wsimport использует JAX-WS 2.1, а компилятор использует JAX-WS 2.2.

Может кто-нибудь подтвердить мое подозрение? Или, если я ошибаюсь, может у вас есть идея, что может быть причиной этого?

Спасибо.

ОБНОВЛЕНО/ПОДТВЕРЖДЕНИЕ ПРОБЛЕМЫ Клиент веб-службы расширяет javax.xml.ws.Service и возникает ошибка, когда клиент пытается вызвать конструктор суперкласса с тремя аргументами. Поскольку у суперкласса нет конструктора с тремя аргументами, он терпит неудачу.

javax.xml.ws.Service находится в JDK SE 1.6 и JAX-WS 2.1 как неправильная версия.

javax.xml.ws.Service находится в JAX-WS 2.2 в качестве правильной версии.

Ошибка возникает три раза, так как она находится в трех переопределенных конструкторах, но с той же ошибкой, поэтому я включил ее только один раз.

cannot find symbol
symbol  : constructor Service(java.net.URL,javax.xml.namespace.QName,javax.xml.ws.WebServiceFeature[])
location: class javax.xml.ws.Service


<plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>jaxws-maven-plugin</artifactId>
            <version>1.12</version>
            <executions>
                <execution>
                    <goals>
                        <goal>wsimport</goal>
                    </goals>
                    <configuration>
                        <wsdlFiles>
                            <wsdlFile>*path to WSDL*</wsdlFile>
                        </wsdlFiles>
                        <wsdlLocation>*url to WSDL*</wsdlLocation>
                        <staleFile>${project.build.directory}/jaxws/stale/BudgetCheckingServiceService.stale</staleFile>
                    </configuration>
                    <id>wsimport-generate-BudgetCheckingServiceService</id>
                    <phase>generate-sources</phase>
                </execution>
            </executions>
            <dependencies>
                <dependency>
                    <groupId>com.sun.xml.ws</groupId>
                    <artifactId>jaxws-tools</artifactId>
                    <version>2.2.6-SNAPSHOT</version>                            
                </dependency>

                <dependency>
                    <groupId>javax.xml</groupId>
                    <artifactId>webservices-api</artifactId>
                    <version>1.4</version>
                </dependency>
            </dependencies>
            <configuration>                    
                <sourceDestDir>${project.build.directory}/generated-sources/jaxws-wsimport</sourceDestDir>
                <xnocompile>true</xnocompile>
                <verbose>true</verbose>
                <extension>true</extension>
                <catalog>${basedir}/src/jax-ws-catalog.xml</catalog>
            </configuration>
        </plugin>

Ответы

Ответ 1

Как вы можете видеть в jaxws-maven-plugin-1.12 pom, у него есть зависимость jaxws-tools-2.1.7. Ну, ты переубедил его через пом. Но это переутомление работает до тех пор, пока версия с расширенными версиями (2.2.6-SNAPSHOT) совместима с api-совместимой версией плагина по умолчанию (2.1.7).

Очевидно, что на основе ваших замечаний они не совместимы с api. Итак, как я вижу, это не сработает. Здесь приведена ссылка.

Запустить mvn install с флагом -X для определения точной версии jaxws-tools используется этим плагином. Сделайте пастабин, если вы не возражаете, тогда мы тоже можем посмотреть!

РЕДАКТИРОВАТЬ: Одна вещь, которую вы можете сделать, это: обновите jaxws-tools maven-jaxws-plugin до нужной вам версии. И затем устраните проблемы из-за несовместимости api (например, проблемы с конструктором). Затем отправьте патч в вверх по течению.

Ответ 2

У меня была аналогичная проблема, и она была решена путем размещения файла webservices-api.jar в моей папке %JDK_HOME%/jre/lib/endorsed.