Welcome!

Machine Learning Authors: Pat Romanski, Yeshim Deniz, Elizabeth White, Liz McMillan, Zakia Bouachraoui

Related Topics: Java IoT, Industrial IoT, @CloudExpo

Java IoT: Blog Feed Post

Solving the XML Problem with Jackson | @CloudExpo #API #Java #JSON #Cloud

Jackson is a popular library for handling JSON in Java applications, quickly becoming the de-facto standard in the ecosystem

Solving the XML Problem with Jackson
By Eugen Paraschiv

Jackson is a popular library for handling JSON in Java applications, quickly becoming the de-facto standard in the ecosystem. Starting with version 2, it has also introduced a mature XML implementation alongside its established JSON support.

Adding Jackson XML to the Project
Adding the Jackson XML module to the project only needs a single dependency - the Jackson XML module itself:

<dependency>
<groupId>com.fasterxml.jackson.dataformat</groupId>
<artifactId>jackson-dataformat-xml</artifactId>
<version>2.9.0</version>
</dependency>

And in Gradle:

compile "com.fasterxml.jackson.dataformat:jackson-dataformat-xml:2.9.0"

This will automatically pull in all of the other Jackson dependencies that are needed:

Note that the Woodstox StAX library can be excluded and replaced with any other valid implementation of the StAX API.

Configuring the Jackson XML Module
Jackson is typically used by means of an ObjectMapper instance. In order to work with XML, we'll instead use the XmlMapper class. This is a direct extension of ObjectMapper and can be used as a replacement, with the exact same API we're already used to.

The absolute simplest way of working with this is to just use the default configuration:

ObjectMapper objectMapper = new XmlMapper();

However, if we need additional configuration, we can instead construct the Jackson Module manually and set it up as necessary:

JacksonXmlModule xmlModule = new JacksonXmlModule();
xmlModule.setDefaultUseWrapper(false);
ObjectMapper objectMapper = new XmlMapper(module);

As of version 2.9.0, the only configuration options for the XML Module are:

  • setDefaultUseWrapper - defines whether or not to use a wrapper for non-annotated List properties by default
  • setXMLTextElementName - defines the virtual name to use when processing character data sections - when not binding to Java beans

Due to the fact that the XmlMapper extends the standard ObjectMapper, we can essentially use all of the standard Jackson ObjectMapper configuration settings and APISs.

For example, we can configure it to produce indented output as follows:

objectMapper.enable(SerializationFeature.INDENT_OUTPUT);

Note that some of these settings might not work with some XML implementations. For example, older versions of Jackson XML depended on Stax2Writer, which didn't support writing raw characters to the stream. This means that it doesn't support writing the raw newlines and indentations needed for the INDENT_OUTPUT feature to work.

Object Serialization
Jackson is best known for its ability to serialize POJOs into JSON and back, by means of standard conventions and - where necessary - special annotations to give clues to the Jackson library.

As already mentioned, the XmlMapper object directly replaced ObjectMapper, only it works in terms of XML instead of JSON. This means that the API is exactly the same, and it can be used as a direct replacement.

Writing XML
Writing XML is done using the various
writeValue methods that Jackson exposes. For example, marshalling some object to XML is done simply by using the writeValueAsString API:

String xml = objectMapper.writeValueAsString(input);

The standard versions of this all exist and work as expected:

  • Writing to a String
  • Writing to a Byte Array
  • Writing to a java.io.OutputStream - e.g. for streaming over a network connection
  • Writing to a java.io.Writer
  • Writing to a java.io.File

Reading XML
As we just explored, we the library handles writing to XML quite well.

We can also read XML, using the various readValue APIs that are part of provided by the ObjectMapper.

For example, reading some XML from an InputStream into a Java Bean:

MyBean bean = objectMapper.readValue(inputStream, MyBean.class);

Again, the standard versions of this all exist, and work as expected:

  • Reading from a String
  • Reading from a Byte Array
  • Reading from a java.io.InputStream - e.g. for streaming over a network connection
  • Reading from a java.io.Reader
  • Reading from a java.io.File

Jackson Annotations for Serialization
The Jackson XML module supports the full range of annotations that Jackson provides for annotating our POJOs
.

This means that we can have one single set of beans, with one set of annotations and, depending on the ObjectMapper instance, we select whether we get XML or JSON. That's a huge benefit when it comes to structuring our code, as we no longer have to worry about translating between different beans that represent essentially the same data just to get different serialization formats.

For example, given the following bean:

@JsonPropertyOrder({"age", "id", "name"})
public class Person {
@JsonProperty("_id")
private String id;

private String name;

private int age;

@JsonIgnore
private String note;
}

will produce this JSON:

{
"age":4,
"_id":"12345",
"name":"George"
}

And this XML:

<Person>
<age>4</age>
<_id>12345</_id>
<name>George</name>
</Person>

Additional Jackson Annotations for XML
The Jackson XML module adds some additional support for XML specific features.
These annotations allow us to control the XML namespace and local name for elements, including the root element, whether a field is rendered in an element or as plain text, whether the content of an element is rendered in a CData wrapper, and whether a collection should use a wrapper element or not.

@JacksonXmlProperty

@JacksonXmlProperty can be applied to any field in a bean to control the details of the element that is being rendered. This annotation allows us to determine the namespace, the local name, and whether the field is serialized as an Element or an Attribute. For example, the following bean:

For example, the following bean:

public class Person {
@JacksonXmlProperty(
isAttribute = true, namespace = "urn:stackify:jacksonxml", localName = "_id")
private String id;

@JacksonXmlProperty(namespace = "urn:stackify:jackson")
private String name;

private String note;
}

This generates the following XML output:

<Person xmlns:wstxns1="urn:stackify:jacksonxml"
wstxns1:_id="12345">
<wstxns2:name xmlns:wstxns2="urn:stackify:jackson">Graham</wstxns2:name>
<note>Hello</note>
</Person>

@JacksonXmlRootElement

The @JacksonXmlRootElement has a similar role to the @JacksonXmlProperty but for the root element of the entire document. This can only adjust the Namespace and Local name - since the root element can never be serialized as an attribute.

For example, let's look at this Java POJO:

@JacksonXmlRootElement(namespace = "urn:stackify:jacksonxml", localName = "PersonData") public class Person {
private String id;

private String name;

private String note;
}

When serialized, this will result in the following XML:

<PersonData xmlns="urn:stackify:jacksonxml">
<id xmlns="">12345</id>
<name xmlns="">Graham</name>
<note xmlns="">Hello</note>
</PersonData>

@JacksonXmlText

Next, let's have a look at the @JacksonXmlText annotation.

Simply put, this indicates that an element should be rendered as plain text without another element containing it.

For example, the following POJO:

public class Person {
private String id;

private String name;

@JacksonXmlText
private String note;
}

Will produce this simple XML output:

<Person>
<id>12345</id>
<name>Graham</name>
Hello
</Person>

Naturally, you do have to be careful using this annotation and make sure you're still generating valid XML.

@JacksonXmlCData

The @JacksonXmlCData annotation indicates that a CData wrapper should be placed around the content of the element. This can be used in conjunction with the @JacksonXmlText if desired to produce a CData wrapper without an element tag.

Let's have a look at a POJO using this annotation:

public class Person {
private String id;

@JacksonXmlCData
private String name;

@JacksonXmlText
@JacksonXmlCData
private String note;
}

This will result in the following XML:

<Person>
<id>12345</id>
<name><![CDATA[Graham]]></name>
<![CDATA[Hello]]>
</Person>

JacksonXmlElementWrapper

The @JacksonXmlElementWrapper annotation is used to override the default setting from setDefaultUseWrapper - as seen above. This can ensure that a collection either does or does not use a wrapper element, and can control what the wrapper element uses for namespace and local name.

When using wrapper elements, we get an additional element added which contains all of the elements from the collection, and when wrapper elements are not used then the individual collection elements are written directly inline:

class Wrapper {
@JacksonXmlElementWrapper(localName = "list")
private List names;
}

This will produce the following XML:

<Wrapper>
<list>
<names>John</names>
<names>Paul</names>
<names>George</names>
<names>Ringo</names>
</list>
</Wrapper>

Whereas, if the JacksonXmlElementWrapper is replaced with:

@JacksonXmlElementWrapper(useWrapping = false)

Then the XML produced won't contain the list element:

<Wrapper>
<names>John</names>
<names>Paul</names>
<names>George</names>
<names>Ringo</names>
</Wrapper>

Supporting JAXB Annotations

The Jackson XML module also has the ability to support the standard JAXB annotations on our beans - instead of needing the Jackson specific ones. This can be useful if we want to use Jackson for the actual XML Serialization but don't want to depend on it at compile time.

This can also be used to allow JAXB to generate our bean definitions from an XML Schema and have Jackson process them.

This functionality is an additional module that needs to be added in for it to work. It doesn't work out of the box like the Jackson annotations do. In order to configure this - we need to add the JaxbAnnotationModule to our ObjectMapper as follows:

objectMapper.registerModule(new JaxbAnnotationModule());

We can now write or generate a Java bean with JAXB annotations and simply process it with this XmlMapper.

For example, the following POJO:

@XmlRootElement(name = "employee")
@XmlAccessorType(XmlAccessType.FIELD)
public class EmployeeBean {
@XmlAttribute(name = "_id")
@XmlID
private String id;

@XmlElement
private String name;

@XmlElement
private String type;
}

Will produce the following XML when marshalled:

<employee _id="12345">
<name>Graham</name>
<type>Developer</type>
</employee>

Partial Reading and Writing
Jackson also has the powerful ability to actually jump into the middle of an existing XML file and either marshall or unmarshall XML to and from that file.

The functionality makes good use of the standard XMLStreamWriter class, and naturally of XMLStreamReader as well. This cool functionality gives us a lot of flexibility to work with existing XML documents and integrate with these cleanly and easily.

Generating XML
The XmlMapper is able to serialize an entire Java bean into a document that is currently being produced, allowing Jackson to integrate and construct the document along with other external actors. This also gives some ability to support constructs that Jackson cannot handle natively - for example, the XML Prolog.

In order to do this, the XmlMapper needs to be called to write values to the XMLStreamWriter object - the same as if we were writing to any other Writer:

StringWriter stringWriter = new StringWriter();
XMLOutputFactory xmlOutputFactory = XMLOutputFactory.newFactory();
XMLStreamWriter sw = xmlOutputFactory.createXMLStreamWriter(stringWriter);

XmlMapper mapper = new XmlMapper();

sw.writeStartDocument();
sw.writeStartElement("root");

mapper.writeValue(sw, employeeBean);
sw.writeComment("Some insightful commentary here");
sw.writeEndElement();
sw.writeEndDocument();

This will produce the following XML:

<?xml version='1.0' encoding='UTF-8'?>
<root>
<employee _id="12345">
<name>Graham</name>
<type>Developer</type>
</employee>
<!--Some insightful commentary here-->
</root>

Here, the XML Prolog, root element, and the comment - are not produced by Jackson XML, but everything inside the EmployeeBean element is.

Consuming XML
The opposite of this is also possible - deserializing a Java bean from the middle of an XMLStreamReader.

This can be especially useful if we only care to have Java bean representations for data in the middle of a larger object - for example, if we are parsing an Atom wrapper around the data we are interested in.

In order to do this, the XmlMapper needs to be called to read values from the XMLStreamReader object - the same as if we were reading from any other Reader.

Let's have a look at a simple example. The following Java code will consume the XML generated above into an EmployeeBeen instance:

XMLInputFactory f = XMLInputFactory.newFactory();
XMLStreamReader sr = f.createXMLStreamReader(new FileInputStream(inputFile));

XmlMapper mapper = new XmlMapper();
sr.next(); // to point to <root>
sr.next(); // to point to root-element under root
EmployeeBeen employee = mapper.readValue(sr, EmployeeBeen.class);
sr.close();

Limitations of the Jackson XML Module
The XML module in Jackson is by no means designed to be an exact replacement for JAXB. There are certain constructs that will work subtly differently between JAXB and Jackson, and there is no guarantee that Jackson will produce identical XML to JAXB.

Note that, unlike with JSON, the outermost object must be a bean type - it can not be a primitive or wrapper type, an enumeration, or a collection. This is a direct result of how XML works - there's no way in XML to represent such a top-level value.

By default, Jackson will always use a wrapper element for collections, which is also different to how JAXB works. This is the major way that the XML produced by Jackson is not compatible with the XML produced by JAXB. Of course, the behavior can be configured, using the JacksonXmlElementWrapper annotation for one field or the setDefaultUseWrapper configuration setting on the XmlMapper globally.

Jackson also has no support for working with specific XML Schemas. It's designed for writing Java Beans first, rather than generating the Java code from pre-existing schemas. Note that this can be solved to an extent by using the JAXB annotation support and generating the beans using the standard xjc tool.

Equally, it has no support for some of the more advanced XML tools - such as XPath or XSLT. If we need this level of support then we should instead use a more full-featured XML solution.

Usage on Android
In the mobile space, Jackson XML works perfectly well on Android. However, the StAX API is not included in the Android JVM, so it needs to instead be bundled manually.

If we're using the Woodstox XML library that Jackson XML depends on by default - there's nothing extra to be done. If, however, we're using an alternative library - then we might need to add that dependency manually:

<dependency>
<groupId>javax.xml.stream</groupId>
<artifactId>stax-api</artifactId>
<version>1.0-2</version>
</dependency</span>

And for Gradle:

compile "javax.xml.stream:stax-api:jar:1.0-2"

Summary
If you're looking for a mature, flexible way of supporting and working with both JSON and XML for the same data, the Jackson XML module is a fantastic library to leverage. It's not only a solid way to go on its own, but it also has the added benefit of being able to mostly reuse the same configuration for both XML as well as JSON.

Typically, this has to be handled using two different libraries with entirely separate configurations.

Finally, beyond flexibility and ease-of-use, the Jackson team has historically placed a strong emphasis on performance. And given that marshalling and unmarshalling of data is a large part of most web applications, choosing the right library to handle all of that work is critical. That, plus a performance monitoring tool such as Retrace will allow you to get the most out of your app.

The post Solving the XML Problem with Jackson appeared first on Stackify.

Read the original blog entry...

More Stories By Stackify Blog

Stackify offers the only developers-friendly solution that fully integrates error and log management with application performance monitoring and management. Allowing you to easily isolate issues, identify what needs to be fixed quicker and focus your efforts – Support less, Code more. Stackify provides software developers, operations and support managers with an innovative cloud based solution that gives them DevOps insight and allows them to monitor, detect and resolve application issues before they affect the business to ensure a better end user experience. Start your free trial now stackify.com

CloudEXPO Stories
Containers and Kubernetes allow for code portability across on-premise VMs, bare metal, or multiple cloud provider environments. Yet, despite this portability promise, developers may include configuration and application definitions that constrain or even eliminate application portability. In this session we'll describe best practices for "configuration as code" in a Kubernetes environment. We will demonstrate how a properly constructed containerized app can be deployed to both Amazon and Azure using the Kublr platform, and how Kubernetes objects, such as persistent volumes, ingress rules, and services, can be used to abstract from the infrastructure.
Business professionals no longer wonder if they'll migrate to the cloud; it's now a matter of when. The cloud environment has proved to be a major force in transitioning to an agile business model that enables quick decisions and fast implementation that solidify customer relationships. And when the cloud is combined with the power of cognitive computing, it drives innovation and transformation that achieves astounding competitive advantage.
Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
"Cloud computing is certainly changing how people consume storage, how they use it, and what they use it for. It's also making people rethink how they architect their environment," stated Brad Winett, Senior Technologist for DDN Storage, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
The cloud competition for database hosts is fierce. How do you evaluate a cloud provider for your database platform? In his session at 18th Cloud Expo, Chris Presley, a Solutions Architect at Pythian, gave users a checklist of considerations when choosing a provider. Chris Presley is a Solutions Architect at Pythian. He loves order – making him a premier Microsoft SQL Server expert. Not only has he programmed and administered SQL Server, but he has also shared his expertise and passion with budding DBAs as a SQL Server instructor at Conestoga College in Kitchener, Ontario. Drawing on his strong disaster-recovery skills, he monitors production environments to swiftly detect and resolve problems before they arise. A self-described adrenaline junkie, Chris likes tackling the biggest database problems and putting out the toughest fires – and hitting the road on his motorcycle.