wsimport - как генерировать классы конечных точек службы и классы JAXB в отдельных проектах / папках - PullRequest
Новая
       79

wsimport - как генерировать классы конечных точек службы и классы JAXB в отдельных проектах / папках

11 голосов
/ 21 ноября 2011

Мы используем нисходящий подход для проекта с несколькими веб-службами (несколько WSDL). Каждый веб-сервис должен быть настроен как отдельный проект и развернут как отдельная война.

Проблема в том, что WSDL делится несколькими общими файлами .xsd. В настоящее время, если мы запускаем wsimport для каждого WSDL, общие классы JAXB дублируются в каждом проекте веб-службы.

В идеале мы хотели бы сгенерировать классы JAXB отдельно в общем общем проекте, а затем повторно использовать проект классов JAXB в каждом из проектов веб-служб, но wsimport не предоставляет возможность пропустить генерацию класса JAXB ИЛИ указать другое место для классов JAXB.

Есть какие-нибудь мысли о том, как я могу разделить классы JAXB между различными конечными точками веб-службы JAX-WS?

Ответы [ 4 ]

13 голосов
/ 01 мая 2012

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

Начиная с JAXB 2.1 RI есть функция, называемая «эпизодами», которую вы можете использовать для облегчения этого.

Допустим, у вас есть схема с именем myschema.xsd. Тогда вам нужно позвонить по следующему номеру: 

xjc -episode myschema.episode myschema.xsd

Это также работает, если вы компилируете несколько файлов xsd с помощью одного вызова. Вызов создаст привязки, а также файл myschema.episode.

Файл эпизода является специальным файлом привязок. Затем вы можете использовать этот файл с wsimport, например: 

wsimport mywsdl.wsdl -b myschema.episode

wsimport теперь будет использовать ранее сгенерированные файлы JAXB и сгенерирует все, что отсутствует.

Подробнее см. на этой странице .

6 голосов
/ 21 ноября 2011

Этого можно добиться с помощью настройки JAXB / JAX-WS .Предположим, у вас есть типы XSD , встроенные в WSDL.Тогда ваши настройки будут выглядеть следующим образом: 

<jaxws:bindings version="2.0"
    xmlns:jaxws="http://java.sun.com/xml/ns/jaxws"
    xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
    wsdlLocation="../wsdl/some.wsdl">

    <jaxws:package name="org.company.project.ws" />

    <!-- XSD types customization within WSDL -->
    <jaxb:bindings node="//xsd:schema">
        <jaxb:schemaBindings>
            <jaxb:package name="org.company.project.beans" />
        </jaxb:schemaBindings>
    </jaxb:bindings>
</jaxws:bindings>

Приведенная выше конфигурация относится к следующей структуре каталогов проекта: 

+-- binding
|   +-- jaxws-binding.xml
+-- wsdl
|   +-- some.wsdl
+-- src
    ...

Если вы используете плагин org.codehaus.mojo:jaxws-maven-plugin, вам нужно указать <bindingDirectory>binding</bindingDirectory>.

Если ваш XSD является внешним по отношению к WSDL, вам нужно указать настройки отдельно: 

+-- binding
|   +-- jaxb-binding.xml
|   +-- jaxws-binding.xml
+-- wsdl
    ...

Тогда jaxb-binding.xml будет выглядеть так: 

<jaxb:bindings version="1.0"
    xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
    xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">

    <jaxb:bindings schemaLocation="my.xsd" node="//xsd:schema">
        <jaxb:schemaBindings>
            <jaxb:package name="org.company.project.beans" />
        </jaxb:schemaBindings>
    </jaxb:bindings>
</jaxb:bindings>
  • Для сборки Ant вы просто генерируете два jar-файла для разных пакетов.
  • Поскольку я лично не знаю способа создания двух JAR-артефактов из одного проекта Maven :), тогда самое простое решение будет для васдля генерации классов JAXB из XSD в проекте project-beans и в проекте project-ws удалите сгенерированные классы JAXB после запуска wsimport (для этого можно использовать плагин ant).
1 голос
/ 21 ноября 2011

Обычно то, что я видел, используя набор инструментов IBM Rational:

Создайте все JAXB и классы обслуживания и сохраните их вместе с проектом сервиса. Затем заново создайте JAXB и клиентские классы служб и сохраните их в клиентском проекте.

Да, это дублирование. Но я думаю, что причина этого в том, что он разделяет интересы поставщиков услуг и потребителей услуг. С точки зрения набора инструментов, как узнать, является ли ваш клиент .NET, C ++ или Java? Или наоборот. Если вы клиент, как вы узнаете, является ли поставщик .NET, C ++ или Java и т. Д.? Вы не Таким образом, IBM предоставляет такой способ разделения интересов.

Теперь недостатком является то, что у вас есть дублирующий код, если у вас есть источник как для поставщика услуг, так и для потребителя. Это может быть трудно поддерживать.

Так что, возможно, было бы лучше сгенерировать сервис и клиента в проект Java (не проект J2EE или веб-проект) и сделать из этого банку. Таким образом, все классы JAXB есть (и только один раз). WSDL есть (один раз). Служба существует один раз и может быть развернута на сервере в EAR или WAR. И клиент существует на тот случай, если вы захотите отдать его кому-нибудь, чтобы он воспользовался вашим сервисом. Если ваш клиент допускает динамическое создание на основе расположения WSDL, даже лучше.

У меня есть сообщение, которое может помочь вам в этом с точки зрения волшебника. Это больше относится к безопасности, но вы можете найти несколько полезных советов.

0 голосов
/ 21 ноября 2011

Если вы используете Maven, вы можете использовать плагин для этого.
Использование плагина JAXB XJC Maven 2

...