InstantiationException during JAXB Unmarshalling (abstract base class, with #XmlSeeAlso concrete sub class) - jaxb

I am running into JAXB Unmarshalling error as below.
The foo.bar.Base is an abstract class, with an #XmlSeeAlso annotation, which lists foo.bar.SubBase (which is a concrete subclass of foo.bar.Base)
Both of the above classes are statically reachable from a main/entry class: com.example.Request
The JAXBContext is create using the packages string variant viz:
JAXBContext.newInstance("com.example",...);
The above created JAXBContext correctly lists all the three classes : com.example.Request, foo.bar.Base and foo.bar.SubBase as "classes known to this JAXBContext"
But it fails at runtime during the unmarshal call below.. I am unable to figure out what is wrong here.
unmarshaller.unmarshal(<some-DOM-Element-Instance>, com.example.Request.class);
Any pointers will be appreciated!
Thanks!
The stacktrace is:
Caused by: javax.xml.bind.UnmarshalException: Unable to create an instance of foo.bar.Base - with linked exception: [java.lang.InstantiationException]
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:642)
at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:254)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.createInstance(UnmarshallingContext.java:609)
at com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.startElement(StructureLoader.java:181)
at com.sun.xml.bind.v2.runtime.unmarshaller.XsiTypeLoader.startElement(XsiTypeLoader.java:76)
at com.sun.xml.bind.v2.runtime.unmarshaller.ProxyLoader.startElement(ProxyLoader.java:55)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:481)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:459)
at com.sun.xml.bind.v2.runtime.unmarshaller.InterningXmlVisitor.startElement(InterningXmlVisitor.java:71)
at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement(SAXConnector.java:148)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:239)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:276)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:245)
at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMScanner.java:122)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:314)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:293)
Caused by: java.lang.InstantiationException
at sun.reflect.InstantiationExceptionConstructorAccessorImpl.newInstance(InstantiationExceptionConstructorAccessorImpl.java:30)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.xml.bind.v2.ClassFactory.create0(ClassFactory.java:123)
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.createInstance(ClassBeanInfoImpl.java:261)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.createInstance(UnmarshallingContext.java:603)
... 69 more
EDIT #Blaise and #Ross
Thank you very much Blaise and Ross for your pointers. I think I should have included the schema that is being worked off, here.
The relevant schema looks like this:
<xs:complexType name="Request">
<xs:sequence>
<xs:element name="selectedBase" form="unqualified" nillable="true" type="xs:anyType" minOccurs="0"/>
<xs:element name="selectedSubBase" form="unqualified" nillable="true" type="ns1:SubBase" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="Base">
<xs:sequence>
<xs:element name="ID" form="unqualified" nillable="true" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="SubBase">
<xs:complexContent>
<xs:extension base="ns1:Base">
<xs:sequence>
<xs:element name="subBaseElement" form="unqualified" nillable="true" type="xs:anyType" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
So the schema doesn't have substitution group definition (so I guess #XmlElementRef doesn't apply here, or would it still work?), but is using extension. The payload will be :
<ns:Request>
<selectedBase>123</selectedBase>
<selectedSubBase>
<ID>321</ID>
<subBaseElement>123</subBaseElement>
</selectedSubBase>
</ns:Request>
So , the element in the payload occuring is <selectedSubBase> and not <selectedBase xsi:type="ns:SubBase"/>
So which strategy would apply here?

The #XmlSeeAlso annotation is used as a convenience mechanism to tell your JAXB impl that metadata should also be created for the referenced classes. While it is most often used to specify subclasses it is not a mechanism to configure inheritance relationships.
Since JAXB is attempting to instantiate an instance of the abstract super class (foo.bar.Base), it appears as though your XML message does not contain enough information to specify the correct sub-type to be unmarshalled.
This can be done with the xsi:type attribute:
http://blog.bdoughan.com/2010/11/jaxb-and-inheritance-using-xsitype.html
You can also use substitution groups (#XmlElementRef), where the element name is used to determine the appropriate sub-type:
http://blog.bdoughan.com/2010/11/jaxb-and-inheritance-using-substitution.html
JAXB implementations (such as EclipseLink JAXB (MOXy)), also contain extensions for handling inheritance:
http://blog.bdoughan.com/2010/11/jaxb-and-inheritance-moxy-extension.html
And if you would like to ignore the inheritance relationship altogether you can use the #XmlTransient annotation:
http://blog.bdoughan.com/2011/06/ignoring-inheritance-with-xmltransient.html

You need to be using XmlElementRef on the field containing the reference to Base, to tell JAXB that it should look at subclasses. JAXB is clearly trying to instantiate your base class (which it can't do, of course).
Have a look at XmlElementRef's docs.

try #XmlSeeAlso
#XmlSeeAlso({ExchangeFormat.class}) public abstract class MapperJsonXml <T>
#XmlRootElement(name="ExchangeFormat") public class ExchangeFormat extends MapperJsonXml<ExchangeFormat>
it works

Related

complexContent restriction: is it XSD 1.0 or Xerces causing this behavior change?

Here is a small schema, and a sample XML file, that will validate successfully at the Xerces-J online validation service if XSD version 1.1 is selected, but not XSD 1.0.
With 1.0 selected, the schema itself is rejected, as invalidly deriving t2 from t1. (The intent is that t1 allows an optional thing and some stuff, and t2 is a restriction that keeps the stuff but forbids the thing.)
The exact complaint from Xerces-J with 1.0 selected is:
[Error] foo.xsd:19:28:rcase-Recurse.1: Group's occurrence range, (0,unbounded), is not a valid restriction of base group's occurrence range, (1,1).
[Error] foo.xsd:19:28:derivation-ok-restriction.5.4.2: Error for type 't2'. The particle of the type is not a valid restriction of the particle of the base.
I think what happens is the containing <sequence> in t2 gets considered "pointless" (2.2.2.2.1 here) because it now has only one child, but the corresponding <sequence> in t1 is not "pointless" because it has two children, and the derivation checker is trying to match the minOccurs and maxOccurs of t2's <group> against those of t1's <sequence>. Somehow, the checker for XSD 1.1 manages to be smarter than that.
So my question (ok, two questions):
Is this behavior in 1.0 an inherent known limit of XSD 1.0 that the derivation rules in 1.1 were updated to fix, or is it a limit of the Xerces-J implementation of 1.0? Does anybody have a 1.0 implementation that accepts this schema?
Given the continued deployment of tools that use 1.0, does anyone know an alternate way to write this schema that will work in 1.0? (I can make this example work by losing the <group> and inlining the <stuff> element both places, but that's not a plan if the real-life group has more than one child).
Edit: even the inlining workaround is unavailing if the element heads a substitution group. That gets reified here as a <choice> group, which again has its minOccurs and maxOccurs mismatch those of the base type's <sequence>.
foo.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
targetNamespace="foo:bar"
xmlns="foo:bar">
<xs:group name="stuffGroup">
<xs:sequence>
<xs:element name="stuff"/>
</xs:sequence>
</xs:group>
<xs:complexType name="t1">
<xs:sequence>
<xs:element name="thing" minOccurs="0"/>
<xs:group ref="stuffGroup" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="t2">
<xs:complexContent>
<xs:restriction base="t1">
<xs:sequence>
<xs:group ref="stuffGroup" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="a" type="t2"/>
</xs:schema>
foo.xml:
<a xmlns='foo:bar'/>
The Microsoft .NET XSD 1.0 based schema validator rejects your schema with an error in line 19 saying (citing first the German message I get from VS): "
Warnung Ungültige Partikelableitung durch Einschränkung - 'Gemäß All:All,Sequence:Sequence -- Recurse-Regel 1 oder Choice:Choice -- RecurseLax ist der Bereich des abgeleiteten Partikels keine gültige Einschränkung des Basispartikelbereichs.'." which I would translate roughly as "Warning invalid particle inference by restriction - according to All:All,Sequence:Sequence -- Recurse-rule 1 oder Choice:Choice -- RecurseLax is the domain of the inferred particle no valid restriction of the base particle domain".
Xmllint ("xmllint: using libxml version 20910"), on the other hand, when trying to validate the sample against the schema with e.g. command line options --schema schema1.xsd sample1.xml reports:
<?xml version="1.0"?>
<a xmlns="foo:bar"/>
sample1.xml validates
I will need to dig deeper in the schema specs the judge what is the right behaviour.

Issues with JAXB bindings

I have a requirement for customizing the JAXB bindings for a SOAP client. I need to impose bindings at specific nodes available in the WSDL. The WSDL schema looks like:
<xs:complexContent mixed="false">
<xs:extension base="q1:RequestBase" xmlns:q1="http://www.epsilon.com/webservices/">
<xs:sequence>
<xs:element minOccurs="0" name="RegisterDate" type="xs:dateTime"/>
</xs:extension>
</xs:complexContent>
I need to apply binding for 'RegisterDate' attribute. I have added the following binding:
parseMethod="com.dunkindonuts.website.loyalty.util.DateAdapter.parseDateTime"
printMethod="com.dunkindonuts.website.loyalty.util.DateAdapter.printDateTime"/>
However, it is not working. When i apply this binding on global level, it works perfectly fine.
Can anyone provide any pointers to resolve this issue?
Regards,
Namit
I can't tell from your original post if your non-global binding included the schema location and/or binding node (xpath)??? something like:
<jxb:bindings schemaLocation="PATH_TO_YOUR_SCHEMA">
<jxb:bindings node="//xs:element[#name='RegisterDate']">
<jxb:property>
<jxb:baseType ...

How To Use ObjectFactory Generated By Jaxb?

I am using Jaxb to generate Java classes. My schema has the following element defined:
<xs:complexType name="AutomobileType" abstract="true">
<xs:sequence>
<xs:element name="Color" type="core:ColorName"/>
<xs:element name="Weight" type="core:PoundsWeightType"/>
<xs:element name="Fuel" type="Fuel"/>
<xs:element name="NumDoors" type="xs:nonNegativeInteger"/>
<xs:element name="NumCylinders">
<xs:simpleType>
<xs:restriction base="xs:int">
<xs:minInclusive value="1"/>
<xs:maxInclusive value="12"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="Automobile" type="AutomobileType"/>
As you can see, I have one element called Automobile.
Jaxb creates the classes and an ObjectFactory that I use to create instances of Automobile. The thing that baffles me is the method to create an instance of Automobile is as follows:
public JAXBElement<AutomobileType> createAutomobile(AutomobileType value)
Why does the createAutomobile method have an argument? How do I use this method?
I tried the following:
ObjectFactory objectFactory = new ObjectFactory();
objectFactory.createAutomobile(new Automobile());
but this does not compile because the Automobile class is abstract and therefore I cannot create an instance.
There is another method :
public AutomobileType createAutomobileType();
In JAXB, the xsd:complexType "AutomobileType" construct maps the class of the same name. It is meant to be the data structure that is equivalent to that XML schema type.
The JAXBElement<> is a (parameterized) wrapper type that associates the java object and the element name and namespace, and that's why its constructor takes an AutomobileType object as parameter in the constructor, in addition to the element namespace and the element name.
The generated ObjectFactory "createAutomobile(..)" is just a convenience method to wrap that constructor, hard-coding your namespace and element name from your XML schema.
While this dichotomy is not all straight forward at first, consider that you could have another element by another name
They would be structurally equivalent, but the element name would be different. You would have another ObjectFactory method "createMotorcycle(...)".
You can create an un-named automobileType object for the purpose of building the contents of the xml element, and then tell JAXB exactly which XML element it should be represented as.
I can't recommend enough reading the JAXB documentation on the topic.

JAXB: Ignore order of elements while using xs:extension

We are using JAXB for Java-xml binding.We initially created domain class and then using schemagen commandline tool the following schema has been generated. But generated schema is not valid, giving following error message.
Error Message:
cos-all-limited.1.2: An all model group must appear in a particle with {min occurs} = {max occurs} = 1, and that particle must be part of a pair which constitutes the {content type} of a complex type definition.
Use Case:
There are two classes Emp(Base class) and Dept(Child class).
1. There is no restriction on the elements sequence(means empId, deptId and deptName can appear in any order). so we used xs:all element
2. In Dept class, deptId field should appear only once(minOccurs =1, maxOccurs=1) and deptName is optional.
As per my usecase i am unable to generate valid schema. I did search on google. But i couldn't find the solution. So i am anticipating experts can answer this query. Could you please look into below classes,schema and guide me in the right direction.
NOTE: please don't suggest me to create some temporary domain classes.
Thanks in anticipation.
Emp.java
#XmlAccessorType(XmlAccessType.FIELD)
#XmlType(name="EmpType", propOrder={})
#XmlRootElement
public class Emp {
#XmlElement(name="empId", required = true)
private String empId;
}
Dept.java
#XmlAccessorType(XmlAccessType.FIELD)
#XmlType(name="DeptType", propOrder={})
public class Dept extends Emp
{
#XmlElement(name="deptId", required = true)
private String deptId;
private String deptName;
}
Schema1.xsd
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<xs:schema version="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="emp" type="EmpType"/>
<xs:complexType name="EmpType">
<xs:sequence>
<xs:element name="empId" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="DeptType">
<xs:complexContent>
<xs:extension base="EmpType">
<xs:all> <!--showing error message, mentioned above -->
<xs:element name="deptId" type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:element name="deptName" type="xs:string" minOccurs="0"/>
</xs:all>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:schema>
The document structure that you are trying to allow is actually difficult to represent in an XML schema. You may not be able to generate it from a JAXB (JSR-222) annotated model. You do however have a couple of options:
Option #1 - Generate a Simpler XML Schema
If you are not validating XML content with your XML schema and are simply using it as documentation that people can use as a guide then I would drop the all sections and use sequence instead. This will work better with the inheritance relationship that you have. If you don't specify an instance of Schema on the Unmarshaller the order of elements is not enforced so you will be able to read all the XML documents that meet your rules.
Option #2 - Create Your Own XML Schema
If you want the XML schema to exactly reflect all the possible accepted inputs then you will need to write it yourself. You can reference this existing XML schema by using the package level #XmlSchema annotation.
#XmlSchema(location = "http://www.example.com/package/YourSchema.xsd")
package com.example;
import javax.xml.bind.annotation.XmlSchema;

Unmarshalling based on Concrete Instance

I am a new comer to JaxB World and I am facing one problem w.r.t. unmarshalling of the stored xml content into java class object. Problem description is as follows. Let me know if this is solvable
I have my xsd file which contains following content(this is just a example)
Student info
<xs:complexType name="specialization" abstract="true">
</xs:complexType>
<xs:complexType name="Engineering">
<xs:complexContent>
<xs:extension base="specialization">
<xs:sequence>
<xs:element name="percentage" type="xs:int" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="Medical">
<xs:complexContent>
<xs:extension base="specialization">
<xs:sequence>
<xs:element name="grade" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Now all the corresponding java classes are generated by compiling the xsd. Now lets assume in my application i will set the specialization attribute of Student info by constructing Engineering class instance. So after all the operation when i save
the xml file that get saved will have the entry like below
<Student>
<Name>Name1</Name>
<Specialization>
<percentage>78<percentage>
</Specialization>
</Student>
Now when the above content goes for unmarshalling, unmarshalling fails saying unexpected element . I guess this is b'cos Specialization element is of type specialization it calls unmarshalling on itself rather than derived object which is stored.
I hope my explanation is clear. Is there any way that we can unmarshall based on derived class instanse type. The xsd and bindings.xjb file is completely in my control so i can add or modify any entries/info which conveys to unmarshalling rules to unmarshall on derived class.
Thanks for your Suggestion but the it still not working for me.
Here is what I tried
Option #1 - xsi:type
My xsd looks same as what is explained in the example but still the Xsi:type doesn't come in the resulted xml. Do i need to add any other setting while compiling? Which JaxB version should i use for this?
Option#2 - Substitution Groups
When i added the substitution entry part in my xsd, XSD compilation failed saying duplicate names "Engineering" and "Medical". I guess element name and type Name being same compilation cribs(All engineering, Medical,specialization being same both in type definition and element Name)
I can't modify the generated classes as we are using Model driven Architecture. Only thing that is in hand is xsd. Any modification to the xsd is allowed. Ideally First option should have worked. But can't figure out why it is not working. Let me know if you have some suggestion to narrow down the problem.
There are different ways of representing Java inheritance in XML when using JAXB:
Option #1 - xsi:type
In this representation an attribute is used to indicate the subtype being used to populate this element.
<Student>
<Name>Name1</Name>
<Specialization xsi:type="Engineering">
<percentage>78<percentage>
</Specialization>
</Student>
For a detailed example see:
http://blog.bdoughan.com/2010/11/jaxb-and-inheritance-using-xsitype.htmlhtml
Option #2 - Substitution Groups
Here an element name is used to indicate the subtype. This corresponds to the schema concept of substitution groups and leverages JAXB's #XmlElementRef annotation:
<Student>
<Name>Name1</Name>
<Engineering>
<percentage>78<percentage>
</Engineering>
</Student>
For a detailed example see:
http://blog.bdoughan.com/2010/11/jaxb-and-inheritance-using-substitution.html

Resources