JAXB Unmarshaller tries to instantiate abstract class ignoring xsi:type if it is a list element

[Tomas-Kraus]

JAXB ignores the xsi:type in SOAP request and tries to instantiate abstract class if the abstract element is in a list

2017-08-21 14:58:37.982 [http-nio-8080-exec-3] INFO com.sun.xml.bind.v2.ClassFactory - failed to create a new instance of class com.generali.ws.bipro.v2_6.datentypen.STEBauausfuehrung
java.lang.InstantiationException: null
at sun.reflect.InstantiationExceptionConstructorAccessorImpl.newInstance(Unknown Source) ~[?:1.8.0_101]
at java.lang.reflect.Constructor.newInstance(Unknown Source) ~[?:1.8.0_101]
at com.sun.xml.bind.v2.ClassFactory.create0(ClassFactory.java:133) ~[jaxb-core-2.2.11.jar:2.2.11]
at com.sun.xml.bind.v2.ClassFactory.create(ClassFactory.java:142) [jaxb-core-2.2.11.jar:2.2.11]
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.createInstance(UnmarshallingContext.java:687) [jaxb-impl-2.2.11.jar:2.2.11]
at com.sun.xml.bind.v2.model.impl.RuntimeClassInfoImpl$TransducerImpl.parse(RuntimeClassInfoImpl.java:392) [jaxb-impl-2.2.11.jar:2.2.11]
at com.sun.xml.bind.v2.runtime.unmarshaller.TextLoader.text(TextLoader.java:69) [jaxb-impl-2.2.11.jar:2.2.11]
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.text(UnmarshallingContext.java:589) [jaxb-impl-2.2.11.jar:2.2.11]
at com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.processText(StAXStreamConnector.java:338) [jaxb-impl-2.2.11.jar:2.2.11]
at com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.handleEndElement(StAXStreamConnector.java:216) [jaxb-impl-2.2.11.jar:2.2.11]
at com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:185) [jaxb-impl-2.2.11.jar:2.2.11]
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:415) [jaxb-impl-2.2.11.jar:2.2.11]
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:394) [jaxb-impl-2.2.11.jar:2.2.11]

SOAP Request:
<sachen:Bauausfuehrung xsi:type="dt:STE_BauausfuehrungBasis">903</sachen:Bauausfuehrung>

Generated Java Code
protected List bauausfuehrung;

xsd cutouts
<xsd:element name="Bauausfuehrung" type="dt:STE_Bauausfuehrung" minOccurs="0"
maxOccurs="unbounded"/>

<xsd:complexType name="STE_Bauausfuehrung" abstract="true">
xsd:simpleContent
<xsd:extension base="xsd:string"/>
</xsd:simpleContent>
</xsd:complexType>

<xsd:complexType name="STE_BauausfuehrungBasis" final="#all">
xsd:simpleContent
<xsd:restriction base="dt:STE_Bauausfuehrung">
<xsd:enumeration value="001">
xsd:annotation
xsd:documentation001</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="002">
xsd:annotation
xsd:documentation002</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>

[Tomas-Kraus]

@NiasSt90 Commented
the bug applies to both "marshal" and "unmarshal".
On "marshal" the xsi:type information is lost.

i've created a reproducer project

[Tomas-Kraus]

@NiasSt90 Commented
pull request #1155 provides a fix for these issue.

[Tomas-Kraus]

• Issue Imported From: JAXB Unmarshaller tries to instantiate abstract class ignoring xsi:type if it is a list element javaee/jaxb-v2#1135
• Original Issue Raised By:@RenePinnow
• Original Issue Assigned To: Unassigned

[jonashackt]

Any progress on that? A PR is waiting for long now (in the old project javaee/jaxb-v2@d367678) - not really a big change, but would be great to see it in an upcoming release :)

[ehambuch]

As we are also struggling with the same issue: is there any workaround known? Maybe setting the base class to a concrete one in the schema or something else?

[ehambuch]

I have temporarily solved that issue in the following way: I edited the BiPRO-Schema-XSD in a way that every Element with an (abstract) STE-Type and maxOccurs=unbounded (which would be generated into a List in the corresponding JAXB-Class) is changed to maxOccurs=1. From a business perspective this works for us at the moment, nevertheless not a proper general workaround for the issue above.

[NiasSt90]

Am Donnerstag, 4. Juli 2019, 01:43:10 CEST schrieb Eric Hambuch:

I have temporarily solved that issue in the following way: I edited the BiPRO-Schema-XSD in a way that every Element with an (abstract) STE-Type and maxOccurs=unbounded (which would be generated into a List<STE-Type> in the corresponding JAXB-Class) is changed to maxOccurs=1. From a business perspective this works for us at the moment, nevertheless not a proper general workaround for the issue above.

the fix is only a one-liner. (see my pull request at https://github.com/ javaee/jaxb-v2#1155) I've build my own jaxb version and used them in jboss-eap application servers and a thorntail project without problems so far. regards, msc