EclipseLink MOXy and the Java API for JSON Processing - Object Model APIs

The Java API for JSON Processing (JSR-353) is the Java standard for producing and consuming JSON which was introduced as part of Java EE 7.  JSR-353 includes object (DOM like) and stream (StAX like) APIs.  In this post I will demonstrate the initial JSR-353 support we have added to MOXy's JSON binding in EclipseLink 2.6.  You can now use MOXy to marshal to:

• javax.json.JsonArrayBuilder
• javax.json.JsonObjectBuilder

 And unmarshal from:

• javax.json.JsonStructure
• javax.json.JsonObject
• javax.json.JsonArray

You can try this out today using a nightly build of EclipseLink 2.6.0:

• http://www.eclipse.org/eclipselink/downloads/nightly.php

The JSR-353 reference implementation is available here:

• https://java.net/projects/jsonp/downloads/download/ri/javax.json-ri-1.0.zip

Mapping Bad XML - Enumerated Collection Elements

In a previous post I introduced EclipseLink JAXB (MOXy)'s @XmlVariableNode extension.  In this post I'll demonstrate how @XmlVariableNode could be leveraged to handle an interesting question I came across on Stack Overflow.  In that question instead of a collection being represented with an element that appeared multiple times, the element name contained the index.  While I would never recommend structuring your XML document this way sometimes you encounter it and need to be able to map it.

MOXy's @XmlVariableNode - JSON Schema Example

We are in the process of adding the ability to generate a JSON Schema from your domain model to EclipseLink MOXy.  To accomplish this we have created a new Variable Node mapping. In this post I will demonstrate the new mapping by mapping a Java model to a JSON Schema.

You can try this out today using a nightly build of EclipseLink 2.6.0:

• http://www.eclipse.org/eclipselink/downloads/nightly.php

MOXy's Object Graphs - Handling Inheritance

In previous posts we have explored how object graphs can be defined through metadata and programatically.  In this post I'll demonstrate the impact of inheritance in your domain model on how you define object graphs.

You can try this out today by downloading an EclipseLink 2.5.0 nightly download starting on March 24, 2013 from:

• http://www.eclipse.org/eclipselink/downloads/nightly.php

MOXy's Object Graphs & Dynamic JAXB

JAXB (JSR-222) makes it easy for you to convert instances of your domain classes to/from XML.  The EclipseLink MOXy implementation offers an extension called Dynamic JAXB where instead of real classes you have instances of a map like class called DynamicEntity. You can access the data on your DynamicEntity using get and set methods that take the property name (i.e. customer.get("address") and customer.set('name", "Jane Doe").

In this post, first we will bootstrap a dynamic JAXBContext based on an external mapping file.  Then we unmarshal an XML document to dynamic entities, and finally we will apply an object graph to scope the resulting JSON output.

You can try this out today by downloading an EclipseLink 2.5.0 nightly download starting on March 24, 2013 from:

• http://www.eclipse.org/eclipselink/downloads/nightly.php

MOXy's Object Graphs - Partial Models on the Fly to/from XML & JSON

In a previous post I introduced how MOXy's Object Graph feature allows you to input and output partial models.  In that example I demonstrated how to define a partial model via metadata.  In this example we will create the object graphs programmatically.  This gives you additional flexibility when you need to create one on the fly.

You can try this out today by downloading an EclipseLink 2.5.0 nightly download starting on March 24, 2013 from:

• http://www.eclipse.org/eclipselink/downloads/nightly.php

MOXy as Your JAX-RS JSON Provider - MOXyJsonProvider

In a previous post I demonstrated how you can implement a MessageBodyReader/MessageBodyWriter to leverage  EclipseLink JAXB (MOXy)'s JSON binding in a JAX-RS service.   MOXy now includes an implementation (MOXyJsonProvider) that can be used directly or extended to make the integration even easier.

Extending JAXB - Representing Metadata as JSON

In previous posts I have described the XML mapping document and JSON-binding extensions in EclipseLink JAXB (MOXy).   Since MOXy has a JAXB model for its mapping document we were able to eat our own dog food, and now MOXy offers a JSON mapping document.

An external metadata representation is useful when:

• You cannot modify the domain model (it may come from a 3rd party).
• You do not want to introduce compile dependencies on JAXB APIs (if you are using a version of Java prior to Java SE 6).
• You want to apply multiple JAXB mappings to a domain model (you are limited to one representation with annotations).
• Your object model already contains so many annotations from other technologies that adding more would make the class unreadable.

MOXy as Your JAX-RS JSON Provider - Client Side

Recently I posted how to leverage EclipseLink JAXB (MOXy)'s JSON binding to create a RESTful service.  In this post I will demonstrate how easy it is to take advantage of MOXy's JSON binding on the client side.

• MOXy as Your JAX-RS JSON Provider - Server Side
• MOXy as Your JAX-RS JSON Provider - Client Side
• MOXy as Your JAX-RS JSON Provider - MOXyJsonProvider 

MOXy as Your JAX-RS JSON Provider - Server Side

In a previous series of posts I covered how EclipseLink JAXB (MOXy) can be leveraged to create a RESTful data access service.  In this post I will cover how easy it is to leverage MOXy's JSON binding on the server side to add support for JSON messages based on JAXB mappings.

• MOXy as Your JAX-RS JSON Provider - Server Side
• MOXy as Your JAX-RS JSON Provider - Client Side 

UPDATE

MOXy now includes an implementation of MessageBodyReader/MessageBodyWriter to make it even easier to leverage MOXy's JSON binding in a JAX-RS application.

•  MOXy as Your JAX-RS JSON Provider - MOXyJsonProvider

JAXB and Inheritance - EclipseLink MOXy's @XmlClassExtractor

In a previous post I covered how JAXB's XmlAdapter could be leveraged to use a node unique to the subtype as the inheritance indicator.  In this post I'll demonstrate that if that node is an XML attribute, then EclipseLink JAXB (MOXy)'s @XmlClassExtractor could be leveraged to do the same thing in fewer lines of code.

JAXB and Namespace Prefixes

In a previous post I covered how to use namespace qualification with JAXB.  In this post I will cover how to control the prefixes that are used.  This is not covered in the JAXB (JSR-222) specification but I will demonstrate the extensions available in both the reference and EclipseLink MOXy implementations for handling this use case.

Mapping Objects to Multiple XML Schemas - Weather Example

I have written previous posts on EclipseLink JAXB (MOXy)'s @XmlPath and external binding file extensions.  In this post I will demonstrate how powerful these extensions are by mapping a single object model to two different XML schemas.  To make the example more "real", the XML data will come from two different services that provide weather information:  Google and Yahoo.

Binding to JSON & XML - Geocode Example

In a previous post I introduced the JSON binding that was added in the MOXy component in EclipseLink 2.4.  In that post I explained how the same metadata that is used for XML binding can be directly applied to JSON binding.  In this post I will demonstrate how powerful this is, by mapping one object model to both XML and JSON using the same set of metadata.  Google Maps Geocoding API V2 will be used to provide the XML and JSON inputs for this example.

You can try this out now using a download available from:

• http://www.eclipse.org/eclipselink/downloads/

JSON Binding with EclipseLink MOXy - Twitter Example

In a previous post I described how the Jettison library could be used with any JAXB implementation (Metro, MOXy, JaxMe, etc) to produce/consume JSON.  Now I'll demonstrate the native object-to-JSON binding MOXy JAXB introduced in EclipseLink 2.4.  With MOXy as your JAXB provider you can produce/consume JSON using the standard JAXB APIs (available in Java SE 6) without adding any compile time dependencies.

You can try this out now using a download available from:

• http://www.eclipse.org/eclipselink/downloads/

MOXy Extensible Models - Multiple Versions

Recently I have discussed support for extensible models in EclipseLink JAXB (MOXy) 2.3. The metadata for the extensions is supplied via MOXy's mapping document.  In this post I will demonstrate how to leverage MOXy's support for multiple mapping documents to keep your metadata organized.

MOXy Extensible Models - Refresh Example

In this example we will leverage EclipseLink JAXB (MOXy)'s concepts of externalized metadata (represented as a MetadataSource), and extensible models.  The MetadataSource will be used to define the metadata for the extensions.  In EclipseLink 2.3 we have introduced the ability for a JAXBContext to be "refreshed".  This means that without stopping the application we can supply metadata about new extensions.

Using EclipseLink MOXy with a Metadata Repository

EclipseLink JAXB (MOXy) provides an XML mapping document as an alternative to using annotations.  This mapping document can be provided in many different forms:  resource path, URL, File, Source, etc.  If however you store your metadata in some sort of repository this flexibility might not be enough.  This is why in EclipseLink 2.3 we have introduced a new mechanism to support this use case.

MOXy Extensible Models - Multi-Tenant Example

In a multi-tenant architecture a single application runs on a server, serving multiple client organizations (tenants).  Good multi-tenant applications allow per-tenant customizations.  When these customizations are made to data, it can be difficult for the binding layer to handle them.  In this post I'll demonstrate how to leverage EclipseLink JAXB (MOXy)'s support for extensible models to easily handle this use case.

Extensible Models with EclipseLink JAXB (MOXy)

JAXB is designed to work with domain models that have real fields/properties.  In EclipseLink 2.3, MOXy introduces the concept of virtual properties.  Virtual properties are defined by the MOXy metadata file, and provide a way to extend a class without modifying the source.  In this post I'll describe what virtual properties are, and in upcoming posts I'll cover how they can be leveraged:

•  MOXy Extensible Models - Multi-Tenant Example