Оптимизация WSImport для нескольких WSDL с общими типами - PullRequest
11 голосов
/ 05 августа 2011

Я работаю над довольно крупным проектом WS, включающим более 20 различных веб-сервисов.Эти веб-сервисы, хотя и независимы друг от друга, имеют общий набор общих типов.Мы используем wsimport в качестве цели ant в нашем скрипте сборки для генерации прокси-классов.

Проблема: Поскольку количество наших WS (и соответствующих WSDL) увеличилось, мы заметили, чтовремя сборки для наших прокси-классов было довольно крутым.После дальнейшего исследования (и профилирования) мы обнаружили, что wsimport тратит огромную часть времени на многократную генерацию распространенных типов.Дошло до того, что генерация, компиляция и упаковка этих прокси-классов и их общих типов занимает около 15-20 минут.Для нас это проблема, и мы ищем способы сократить время сборки.

Вопрос: Есть ли способ генерировать общие типы только один раз?Я рассмотрел некоторые решения , найденные поиском в Google.Один из них заключался в написании WSDL-аккумулятора , который анализирует WSDL и объединяет их в один WSDL, поэтому wsimport вызывается только один раз.Другой намекнул на использование файлов эпизодов , но дальнейшее расследование только выявило, что были проблемы с использованием этого подхода.

Примечание: я видел несколько более старых похожих вопросов, но ни на один из них не было ответов.

wsimport нескольких сгенерированных wsdl

Как я могу сказать wsimport, что отдельные файлы WSDL ссылаются на одни и те же классы объектов?

1 Ответ

1 голос
/ 20 февраля 2013

Прежде всего, я бы использовал apache cxf для этой сборки, поскольку он может обрабатывать несколько WSDL одновременно и намного более современен. Это будет намного эффективнее и будет генерировать лучшие классы. Во-вторых, я бы прекратил беспокоиться об этом, если файлы WSDL сильно не изменятся. Вместо этого я бы поместил их в отдельный артефакт и собрал их один раз, а затем импортировал в проект как собственный артефакт. Единственное, что не генерируется в этом архиве, это тестовый код для тестирования конечных точек. Что касается сборки, то конфигурация плагина Maven, которую я использовал с большим успехом, вставлена ​​ниже.

      <plugin>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-codegen-plugin</artifactId>
    <version>${apache.cxf.version}</version>
    <executions>
      <execution>
        <id>generate-sources</id>
        <phase>generate-sources</phase>
        <configuration>
          <sourceRoot>${project.build.directory}/generated-sources/</sourceRoot>
          <defaultOptions>
            <catalog>${wsdlDir}/jax-ws-catalog.xml</catalog>
            <bindingFiles>
              <bindingFile>${wsdlDir}/jaxb-bindings.xml</bindingFile>
              <bindingFile>${wsdlDir}/jaxws-bindings.xml</bindingFile>
            </bindingFiles>
            <noAddressBinding>true</noAddressBinding>
            <extraargs>
              <extraarg>-client</extraarg>
              <extraarg>-xjc-Xbug671</extraarg>-->
              <extraarg>-xjc-mark-generated</extraarg>
            </extraargs>
          </defaultOptions>
          <wsdlOptions>
            <wsdlOption>
              <wsdl>${wsdlDir}/cis.wsdl</wsdl>
            </wsdlOption>
          </wsdlOptions>
        </configuration>
        <goals>
          <goal>wsdl2java</goal>
        </goals>
      </execution>
    </executions>
    <dependencies>
      <dependency>
        <groupId>org.apache.cxf.xjcplugins</groupId>
        <artifactId>cxf-xjc-bug671</artifactId>
        <version>${apache.cxf.xjc.version}</version>
      </dependency>
    </dependencies>
  </plugin>

Это настроено для генерации только из одного WSDL, но можно легко добавить больше WSDL, и я сделал это в других обстоятельствах.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...