Настройка привязки JAXB
При попытке сгенерировать классы из xsd я получил эту ошибку:
java.lang.IllegalArgumentException: Illegal class inheritance loop. Outer class OrderPropertyList may not subclass from inner class: OrderPropertyList
Мой xsd определяет элемент для группировки неограниченного элемента следующим образом:
<element minOccurs = "0" name = "orderPropertyList">
<complexType>
<sequence>
<element maxOccurs = "unbounded" name = "orderProperty" type = "tns:orderProperty" />
</sequence>
</complexType>
</element>
И моя привязка настройки следует, как указано в эта страница, но это не работает. Вот моя привязка:
<jaxb:bindings schemaLocation = "../xsd/Schema.xsd" node = "/xs:schema">
<jaxb:bindings node = "//xs:element[@name='orderPropertyList']">
<jaxb:class name = "OrderPropertyList"/>
</jaxb:bindings>
</jaxb:bindings>
Я намерен создать отдельный класс для orderPropertyList, а не поведение по умолчанию, которое создает внутренний класс внутри корневого элемента xsd.
Я наблюдал за кем-то с таким же намерением здесь и здесь, но у меня это не работает должным образом. :(
Версия JAXB:
Specification-Version: 2.1
Implementation-Version: 2.1.8
Любая помощь?
Ответы 5
Я считаю, что это происходит потому, что сгенерированный Java-класс, представляющий последовательность «orderProperty», сам по себе называется «OrderPropertyList».
Я бы сначала сгенерировал его без каких-либо пользовательских привязок и посмотрел на имена классов и иерархии, которые он генерирует. Затем подумайте, что вы хотите переопределить и как.
На самом деле, когда я удаляю привязку, я веду себя по умолчанию: OrderPropertyList как внутренний класс корневого элемента. Я использую пользовательскую привязку, чтобы избавиться от этой ситуации (даже безуспешно).
Я считаю, что вам нужно:
<jaxb:globalBindings localScoping = "toplevel"/>
Это создаст автономные классы вместо вложенных классов.
Делает
<jaxb:bindings schemaLocation = "../xsd/Schema.xsd" node = "/xs:schema">
<jaxb:bindings node = "//xs:element[@name='orderPropertyList']">
<jaxb:class name = "OrderPropertyList"/>
</jaxb:bindings>
</jaxb:bindings>
является избыточной привязкой, поскольку orderPropertyList по умолчанию сопоставляется с OrderPropertyList. Имя пакета включает имя внешнего класса, в который он вложен по умолчанию, поэтому вы не меняете его.
Кроме того, если вы действительно хотите изменить имя сгенерированного класса, я думаю, что XPath на самом деле будет:
<jaxb:bindings node = "//xs:element[@name='orderPropertyList']/xs:complexType">
с комплексным типом на конце. Я думаю, исключение этого было причиной того, что вы получили сообщение об ошибке.
Без эффекта! Я пробовал использовать верхний уровень и множество комбинаций для выражения xPath. Когда я использую localScoping верхнего уровня, я получаю: [xjc] [ERROR] Класс / интерфейс с тем же именем "order.OrderLineList" уже используется. Используйте настройку класса, чтобы разрешить этот конфликт.
После переопределения всех определений с тем же именем, одно за другим все заработало! Урф! Много работы, в которой задействовано более 15 xsds для генерации классов и разрешения конфликтов ... Спасибо!
Это действительно весело, когда у вас есть такая схема:
<xsd:schema xmlns:xsd = "http://www.w3.org/2001/XMLSchema" elementFormDefault = "qualified" attributeFormDefault = "unqualified" version = "1.0">
<xsd:element name = "TopLevelElement">
<xsd:complexType>
<xsd:sequence>
<xsd:element name = "Something">
<xsd:complexType>
<xsd:sequence>
<xsd:element name = "Something" maxOccurs = "unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name = "somethingFieldA" type = "xsd:string"/>
<xsd:element name = "somethingFieldB" type = "xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
В этом случае кажется, что xjc пытается фактически сгенерировать четыре класса с именем Something, по одному для каждого элемента с именем Something и по одному для каждого из их complexType. Таким образом, вам необходимо предоставить привязку, которая воздействует на каждый из этих четырех элементов сложных типов и конкретно на том уровне, на котором они встречаются в схеме (ну, на самом деле, только три, потому что тогда 4-й может просто стать единственным классом Something).
Мне нужно было настроить схему, подобную представленной jeff303. Мой сценарий немного отличался тем, что схема была встроена в документ WSDL.
Одна вещь, на которую указывает филварнер, заключается в том, что выбор узла для элемента должен заканчиваться на '/ xs: complexType', и это казалось очень важным, поскольку компилятор постоянно генерировал исключение IllegalArgumentException, связанное с циклическим наследованием без него.
Эти сообщения связаны между собой, поэтому я подумал, что обратная ссылка будет полезна тем, кто «погуглил», который оказался здесь.
Проверьте вопрос 7881883
Ввод этого /xs:complexType в конце элемента помог исправить ошибку цикла недопустимого наследования классов.
Это своего рода ужасная ситуация, как всегда генерировать классы без использования внутренних классов? О Боже! Если вы используете Weblogic 10 с jax-ws, у вас не может быть внутренних классов внутри типов запросов / ответов. Грустный!