JAXB Binding Customization

Question

While trying to generate classes from a xsd, i got this error:

java.lang.IllegalArgumentException: Illegal class inheritance loop.  Outer class OrderPropertyList may not subclass from inner class: OrderPropertyList

My xsd define a element to group a unbounded element like this:

  <element minOccurs="0" name="orderPropertyList">
    <complexType>
      <sequence>
        <element maxOccurs="unbounded" name="orderProperty" type="tns:orderProperty" />
      </sequence>
    </complexType>
  </element>

And my customization binding follows as specified on this page, but it doesn´t work. Here my binding:

<jaxb:bindings schemaLocation="../xsd/Schema.xsd" node="/xs:schema">
    <jaxb:bindings node="//xs:element[@name='orderPropertyList']">
        <jaxb:class name="OrderPropertyList"/>
    </jaxb:bindings>
</jaxb:bindings>

My intention is to generate a individual class for orderPropertyList, not the default behave that is generating a inner class inside the root element of the xsd.

I´ve watched someone with the same intention here and here, but it doesn´t work properly for me. :(

JAXB version:

Specification-Version: 2.1
Implementation-Version: 2.1.8

Any help?

Answer 1

I believe what you need to to is set:

<jaxb:globalBindings localScoping="toplevel"/>

This will generate standalone classes instead of nested classes.

Doing

<jaxb:bindings schemaLocation="../xsd/Schema.xsd" node="/xs:schema">
    <jaxb:bindings node="//xs:element[@name='orderPropertyList']">
            <jaxb:class name="OrderPropertyList"/>
    </jaxb:bindings>
</jaxb:bindings>

is a redundant binding, since orderPropertyList will map by default to OrderPropertyList. The name of the package includes the outer class name it is nested in by default, so you're not changing that.

Also, if you did want to change the name of the generated class, I think the XPath would actually be:

<jaxb:bindings node="//xs:element[@name='orderPropertyList']/xs:complexType">

with complexType on the end. I think excluding this was what was causing the error message you got.

Answer 2

It's really fun when you have a schema like the following:

<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>

In this case, xjc seems to be trying to actually generate four classes called Something, one for each element named Something, and one for each of their complexTypes. So you need to provide a binding that hits each of these four elements and complex types specifically at the level where they occur in the schema (well really only three, because then the 4th can just become the lone Something class).

Answer 3

I believe this is happening because it's likely that the generated Java class representing the sequence of "orderProperty" is itself named "OrderPropertyList".

What I would do is first generate it without any custom bindings, and look at the class names and hierarchies that it generates. Then, consider what you want to override, and how.

Answer 4

I needed to do customizations for a schema like the one jeff303 presented. My scenario was slightly different in that the schema was inlined within a WSDL document.

One thing pointed out by philvarner is that the node selection for the element should end with '/xs:complexType' and this seemed very important, as the compiler would continually generate an IllegalArgumentException related to looping inheritance without it.

These posts are related so I figured a link back would be helpful to someone 'googling' that ends up here.

Check out question 7881883

Answer 5

Entering this /xs:complexType at the end of the element helped in fixing the illegal class inheritance loop error.