The case that I noted does not depend on <xs:complexType>
definitions in xsd-schema.
The actual problem was that we have Java classes that extend from a class generated from xml-schema.
And these classes are annotated with @XmlType(name = "")
to make them anonymous (i.e. that generated tag does not contain xsi:type
attribute and the generated xml-file remains valid for the initial-schema.
I found the clue to this solution in java, xsd & marshalling: jre bug, my fault or xsd issues?.
Since I can't modify the xsd (it is too complex and is already shared to the clients of our APIs), the solution is:
Make a jaxb-binder that excludes the complexType to be generated into Java file and says JAXB to use the existing class instead.
Binding file looks like this:
<jxb:bindings schemaLocation="MySchema.xsd">
<jxb:bindings node="//xs:complexType[@name='TheClassYouWantToExclude']">
<jxb:class ref="my.existing.class.TheClassYouWantToExclude"/>
</jxb:bindings>
</jxb:bindings>
In existing class, the class that we need to extend is NOT a JAXB-annotated class, just an abstract class:
package my.existing.class;
public abstract class TheClassFromWhichYouWantToExtend {
}
- The field that links to this class from the parent class is annotated with
@XmlAnyElement(lax = true)
:
package my.existing.class;
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(...)
public class TheClassYouWantToExclude {
// ...
@XmlAnyElement(lax = true)
protected TheClassFromWhichYouWantToExtend theClassFromWhichYouWantToExtend;
}