4

Yesterday I updated java like posted in the title, now JAXB doesn't parse xml anymore. All objects are simply null, nothing seems to be set.

Given this POJO - ListMatchingProductsResponse

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "ListMatchingProductsResponse", propOrder = {
        "listMatchingProductsResult",
        "responseMetadata"
})
@XmlRootElement(name = "ListMatchingProductsResponse")
public class ListMatchingProductsResponse {
    @XmlElement(name = "ListMatchingProductsResult")
    private ListMatchingProductsResult listMatchingProductsResult;
    @XmlElement(name = "ResponseMetadata")
    private ResponseMetadata responseMetadata;
    @XmlAttribute(name = "xmlns")
    private String xmlns;

    public String getXmlns() {
        return xmlns;
    }

    public void setXmlns(String xmlns) {
        this.xmlns = xmlns;
    }


    /**
     * Get the value of ListMatchingProductsResult.
     *
     * @return The value of ListMatchingProductsResult.
     */
    public ListMatchingProductsResult getListMatchingProductsResult() {
        return listMatchingProductsResult;
    }

    /**
     * Set the value of ListMatchingProductsResult.
     *
     * @param listMatchingProductsResult The new value to set.
     */
    public void setListMatchingProductsResult(ListMatchingProductsResult listMatchingProductsResult) {
        this.listMatchingProductsResult = listMatchingProductsResult;
    }

    /**
     * Get the value of ResponseMetadata.
     *
     * @return The value of ResponseMetadata.
     */
    public ResponseMetadata getResponseMetadata() {
        return responseMetadata;
    }

    /**
     * Set the value of ResponseMetadata.
     *
     * @param responseMetadata The new value to set.
     */
    public void setResponseMetadata(ResponseMetadata responseMetadata) {
        this.responseMetadata = responseMetadata;
    }
}

And the ListMatchingProductsResult

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name="ListMatchingProductsResult", propOrder={
    "products"
})
@XmlRootElement(name = "ListMatchingProductsResult")
public class ListMatchingProductsResult {

    @XmlElement(name="Products")
    private ProductList products;

    /**
     * Get the value of Products.
     *
     * @return The value of Products.
     */
    public ProductList getProducts() {
        return products;
    }

    /**
     * Set the value of Products.
     *
     * @param products
     *            The new value to set.
     */
    public void setProducts(ProductList products) {
        this.products = products;
    }

    /**
     * Check to see if Products is set.
     *
     * @return true if Products is set.
     */
    public boolean isSetProducts() {
        return products != null;
    }


    @Override
    public String toString() {
        return MoreObjects.toStringHelper(this)
                .add("products", products)
                .toString();
    }
}

I use this for unmarshalling:

String s = getResult();
// s is the expected xml string
ListMatchingProductsResponse m = JAXB.unmarshal(new StringReader(s), ListMatchingProductsResponse.class);
log.info(m); // ListMatchingProductsResponse@7164e54
log.info(m.getListMatchingProductsResult()); // null

I'm a bit lost as I don't see any kind of reason for this, nor did I find any changes regarding JAXB in the changelog.

What am I doing wrong here?

The following answers didn't solve my issue so far

JAXB Configuration was broken by upgrading from JDK 1.7 to JDK 1.8 u05 for collections

Unmarshalling jaxB doesn't work, objects null

Unmarshall with JAXB doesn't work

UPDATE

I now have included the following dependency to my project

group: 'org.jvnet.jaxb2.maven2', name: 'maven-jaxb2-plugin', version: '0.13.1'

and it works again. So new question - why is that? Is there something missing / a bug in the 121 java release?

Community
  • 1
  • 1
baao
  • 71,625
  • 17
  • 143
  • 203
  • `maven-jaxb2-plugin` is a Maven plugin for code generation, you are not supposed to include it as compile or runtime dependencies. – lexicore Jan 25 '17 at 12:26
  • @lexicore I tried several different jaxb dependencies, none worked - but including above one did. While I get that it doesn't make any sense, I'd like to know why including this makes it work again... – baao Jan 27 '17 at 10:30
  • 1
    `maven-jaxb2-plugin` itself has dependencies to JAXB libraries. So basically you "inherit" dependencies from the Maven plugin (instead of having them on your own). See this: http://stackoverflow.com/questions/26413431/which-artifacts-should-i-use-for-jaxb-ri-in-my-maven-project – lexicore Jan 27 '17 at 10:34
  • Have similar problem with JAXB. First noticed it with jdk1.8.0_102. Haven't had a need before now to investigate and fix – lastnitescurry Feb 03 '17 at 06:16
  • I have a similar issue. I was upgrading from 1.8.0_91 to 1.8.0_121 (to get letsencrypt cert support), but _121 fails to parse my xml (all fields are null). I have tried generating with both JDK, and parsing with both JDKs, and parsing always fails with _121. This sounds like a parsing issue with _121, since _91 can parse XML even when classes are generated with _121. – Klaus Groenbaek Mar 02 '17 at 16:28

4 Answers4

4

I have edited this, as it turns out that the change in the JRE was not technically a bug, but 1.8u91 and previous versions were more lenient, and allowed invalid namespaced XML, and 1.8u101+ breaks if xml is not correctly namespaced.

I have created an example on GitHub to illustrate the difference. Try two run the two mains NoSchema and WithSchema using 1.8u91, and 1.8u101+ to see the difference in behaviour.

In my case the XML contained no default namespace, but the elements were not prefixed with the namespace they belonged to (broker.xml). This worked fine in 1.8u91, but failed in 1.8u101. Although upgrading broke our code, this is technically not Oracles fault, since the XML was incorrectly namespaced.

Klaus Groenbaek
  • 4,820
  • 2
  • 15
  • 30
  • While I was trying to build a standalone example, I discovered the following: ` jaxb2-maven-plugin` creates both a `package-info.java` and an ObjectFactory.java. If I remove the package-info (or its @XmlSchema annotation) then Jaxb also works on u101+. So maybe the older versions was more lenient, and the newer version is more strict. – Klaus Groenbaek Mar 06 '17 at 14:36
  • Life-saver answer - thanks. My object unmarshalling started failing when we upgraded to JRE 1.8.101 and *no* exceptions were being printed to the log. – Joman68 Sep 04 '19 at 04:26
0

I faced this issue of unmarshelling giving null values in jdk 101+ versions and solved by including package-info.java and annotation @javax.xml.bind.annotation.XmlSchema

Below is my code

@javax.xml.bind.annotation.XmlSchema(elementFormDefault=XmlNsForm.QUALIFIED,namespace="http://example.com/api") package org.example;

import javax.xml.bind.annotation.XmlNsForm;
Rohit Poudel
  • 1,793
  • 2
  • 20
  • 24
0

Java8 newer version is more strict, I had same issue and found, we have to specify namespace for each field as follow to validate It worked for me

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "ListMatchingProductsResponse", propOrder = {
        "listMatchingProductsResult",
        "responseMetadata"
})
@XmlRootElement(name = "ListMatchingProductsResponse", namespace="http://example.com/api)
public class ListMatchingProductsResponse {
    @XmlElement(name = "ListMatchingProductsResult", namespace="http://example.com/api)
    private ListMatchingProductsResult listMatchingProductsResult;
    @XmlElement(name = "ResponseMetadata", namespace="http://example.com/api)
    private ResponseMetadata responseMetadata;
    @XmlAttribute(name = "xmlns", namespace="http://example.com/api)
    private String xmlns;
amoljdv06
  • 2,646
  • 1
  • 13
  • 18
0

I faced the same issue when unmarschalling basic, non-namespaced XML using classes generated from a schema with the elementFormDefault property set to qualified. Simply using the (default) unqualified value solved the problem for me :

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           elementFormDefault="unqualified">
...
</xs:schema>
Thomas Naskali
  • 551
  • 5
  • 19