Как разрешить конфликты сторонней XML-схемы? - PullRequest
3 голосов
/ 22 октября 2011

Я работаю с набором файлов дескрипторов схемы, написанных третьей стороной.Мне нужно сгенерировать заглушки JAXB для них.Каждый XSD определяет свой тип сообщения, а также поддерживает несколько простых и сложных типов.Многие из типов являются общими для каждого XSD, но вместо того, чтобы выделять их в отдельный XSD, авторы решили определять их в каждом пространстве имен.Это создает массу коллизий пространства имен, когда я пытаюсь скомпилировать XSD с использованием xjc в один пакет.Я вынужден разделить их на уникальные пакеты.Проблема в том, что это делает их не взаимозаменяемыми, когда они должны быть.Я должен сделать много дополнительных преобразований, чтобы использовать данные из одного типа сообщения в другом типе сообщения.

Мой вопрос: есть ли способ (настройка привязки?) Я могу дать команду xjc использовать один класс Java длякаждый общий тип, а не уникальные классы распределены по разным пакетам?

Вот упрощенный пример.У меня есть два XSD, один для сообщения вставки и другой для ответного сообщения.Ответ предназначен для ссылки на сообщение вставки.

<!-- insert.xsd -->
<xs:schema
    xmlns="msg.insert"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="msg.insert">

    <xs:element name="Message" type="Message" />

    <xs:complexType name="Message">
        <xs:sequence>
            <xs:element 
              maxOccurs="1" 
              minOccurs="1" 
              name="MessageId" 
              type="Identifier" />

            <xs:element 
              maxOccurs="1" 
              minOccurs="1" 
              name="SequenceId" 
              type="Identifier" />
        </xs:sequence>
    </xs:complexType>

    <xs:complexType name="Identifier">
        <xs:sequence>
            <xs:element 
              maxOccurs="1" 
              minOccurs="1" 
              name="ID" 
              type="xs:string" />

            <xs:element 
              maxOccurs="1" 
              minOccurs="1" 
              name="Created" 
              type="xs:dateTime" />
        </xs:sequence>
    </xs:complexType>

</xs:schema>

Вот второй XSD ...

<!-- response.xsd -->
<xs:schema
    xmlns="msg.response"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="msg.response">

    <xs:element name="Message" type="Message" />

    <xs:complexType name="Message">
        <xs:sequence>
            <xs:element 
              maxOccurs="1" 
              minOccurs="1" 
              name="MessageId" 
              type="Identifier" />

            <xs:element 
              maxOccurs="1" 
              minOccurs="1" 
              name="SequenceId" 
              type="Identifier" />

            <xs:element 
              maxOccurs="1" 
              minOccurs="1" 
              name="ReferenceId" 
              type="Identifier" />
        </xs:sequence>
    </xs:complexType>

    <xs:complexType name="Identifier">
        <xs:sequence>
            <xs:element 
              maxOccurs="1" 
              minOccurs="1" 
              name="ID" 
              type="xs:string" />

            <xs:element 
              maxOccurs="1" 
              minOccurs="1" 
              name="Created" 
              type="xs:dateTime" />
        </xs:sequence>
    </xs:complexType>

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

xjc -d java -p example.msg insert.xsd response.xsd

... Я получаю коллизии в классах Message, Identifier и ObjectFactory следующим образом.

[ERROR] A class/interface with the same name "example.msg.Message" is already in use. Use a class customization to resolve this conflict.
  line 8 of insert.xsd

[ERROR] (Relevant to above error) another "Message" is generated from here.
  line 8 of response.xsd

[ERROR] A class/interface with the same name "example.msg.Identifier" is already in use. Use a class customization to resolve this conflict.
  line 15 of insert.xsd

[ERROR] (Relevant to above error) another "Identifier" is generated from here.
  line 16 of response.xsd

[ERROR] Two declarations cause a collision in the ObjectFactory class.
  line 8 of insert.xsd

[ERROR] (Related to above error) This is the other declaration.
  line 8 of response.xsd

Я полностью понимаю, почему xjc жалуется, я пытаюсь найти способ заставить xjc использовать общий класс для типа Identifier, а также разрешить коллизии в классе ObjectFactory.Одним из решений было бы выделить отдельные типы в отдельное пространство имен и ссылаться на них из XSD каждого типа сообщения, но, как уже упоминалось, все они написаны третьей стороной, и у меня нет возможности их изменять.

Пока я собираю каждый XSD в отдельный пакет Java.Это работает, но очень, очень громоздко.

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

Ответы [ 2 ]

2 голосов
/ 29 января 2013

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

-B-XautoNameResolution (without spaces)

Таким образом, любой конфликт имен будет автоматически удален при разборе xml.

Надеюсь, это поможет

0 голосов
/ 08 сентября 2017

Мне пришлось столкнуться с подобной проблемой, чтобы скомпилировать огромную библиотеку XSD (> 1,8 КБ файлов XSD) с большим количеством дублированных типов между XSD.

Единственное возможное решение, которое я нашелдолжен был сгенерировать промежуточную модель с пакетами по умолчанию для каждого пространства имен и обработать ее впоследствии с помощью Java codemodel, перемещая все классы типов в один пакет, сворачивая дублированные классы.

Наконец, мне пришлось взломать маршалинг, чтобы избежать пространства именв свернутых классах.

Кажется, что это сумасшедшее решение, но оно работает просто отлично.

BTW -XautoNameResolution - это просто способ автоматического переименования классов дублированных типов, но это не решает проблему.проблема дублирования.

...