hibernatejaxbjaxb2hyperjaxb

Why does Hyperjaxb3 generate RestItem classes?


I'm using maven-hyperjaxb3-plugin (0.6.1) to generate domain classes from my xsd file. Everything works very well except for one class, and even that works fine until I add more than 23 fields onto it.

Once I exceed that number of fields it generates two classes for my table named ILT: one is called ILT.java and one is called ILTRestItem.java, which I assume is something to do with using these classes with a REST API (something I don't plan to do).

The ILTRestItem class has compile errors. It does a lot of calls to XmlAdapterUtils.unmarshallJAXBElement and the error message is:

The method marshallJAXBElement(Class, QName, Class, BoundType) in the type XmlAdapterUtils is not applicable for the arguments (Class, QName, Class, String)

I am not actually too worried about that error because I would rather it just didn't create the ILTRestItem class at all. The other (smaller) classes work fine and my goal is for ILT to do the same thing.

If I run the jaxb2 plugin (maven-jaxb2-plugin) and use that to generate the classes there is no ILTRestItem generated and the classes are the right ones, but they are, of course, missing the JPA annotations. That leads me to suspect that Hyperjaxb3 is responsible for generating the ILTRestItem class, but I've looked through the source code hoping to see classes with something like 'RestItem' in them and there aren't any.

One relevant point is that I am using single table inheritance here. The ILT class and another class (IFT) use the same underlying table (Transaction) and they both extend the Transaction class. If I detach ILT from Transaction and make it a non-inherited class the ILTRestItem no longer generates.

Lots of searches of both JAXB2 and HyperJaxb3 and I don't find any reference to RestItem or just why it is generated (or which of them does it). My hope is there is some config switch to turn off RestItem generation but so far I can't see it.

For completeness I should add I tried switching out different fields to see if one of them was the trigger for this behaviour and it isn't. It really seems to be the number of fields, or possibly the total length of the record.

Also: JPA 2.1 and the relevant maven fragment is:

    <plugin>
        <groupId>org.jvnet.hyperjaxb3</groupId>
        <artifactId>maven-hyperjaxb3-plugin</artifactId>
        <version>0.6.1</version>
        <dependencies>
            <dependency>
                <groupId>com.xyz</groupId>
                <artifactId>ims-core-partner</artifactId>
                <version>${project.version}</version>
            </dependency>
        </dependencies>
        <executions>
            <execution>
                <goals>
                    <goal>generate</goal>
                </goals>
            </execution>
        </executions>
        <configuration>
            <variant>jpa2</variant>
            <extension>true</extension>
                    <args>
                        <arg>-extension</arg>
                        <arg>-XtoString</arg>
                        <arg>-Xannotate</arg>
                    </args>
        </configuration>
    </plugin>

The dependency is to get a couple of custom annotations in that attach using annox.

Finally here is the relevant fragment from my xsd file:

<complexType name="ILT">
    <xsd:annotation>
        <xsd:appinfo>
            <hj:entity>
            <orm:inheritance strategy="SINGLE_TABLE"/>
            <orm:discriminator-value>ILT</orm:discriminator-value>
            </hj:entity>
        </xsd:appinfo>
    </xsd:annotation>
   <xsd:complexContent>
    <xsd:extension base="tns:Transaction">
        <xsd:sequence>
        <element name="iltType" type="tns:ItemType">
        </element>
        <element name="investmentOrderId" type="string">
        </element>
...

This does all work, as long as my field list is short enough.


Solution

  • Funny how once you put in a question here the answer turns up in the next 30 minutes. Sort of anyway. The problem I had was triggered by my having defined the same field in the ILT class (the one generating the ILTRestItem) and the Transaction class (the one it inherits from). Quite reasonably it was trying to split that out into a separate table and do a join. When I removed that field from ILT the problem vanished. I'm not sure how I missed that it was being cause by a particular field, I think I may have come to that conclusion before I upgraded to the latest version.