JAX-RS 2.0 : Custom Content Handling
I triedĀ to think of a better title, but failed to come up with one ! Please bear with meā¦ā¦.
The JAX-RS 2.0 specification allows us to seamlessly marshal/unmarshal JAXB objects to/from HTTP request/response bodies. Simply put, we can just work with the domain objects without being worried about the low level XML serialization within JAX-RS based solutions.
Before we begin, here is the GitHubĀ linkĀ to the source code referenced below ā not much, but just in case you need to peek in.
Development environment
- Java EE 7 (of course!)
- JDK 8- donāt get excited, there are no lambdas in there as yet!
- Netbeans 8
- Wildfly 8 and GlassFish 4 (yes, tested on both servers) ā itās just about switching servers in Netbeans and takes anywhere b/w 15-30 seconds. So itās not really that big a deal!
Let us first go through the use cases which demonstrates the out-of-the-box capabilities of JAX-RS implementations in order to deal with JAXB annotated entities/domain objects over the wire.
Here is a simple example where in we try to āgetā a representation of our domain object which happens to be JAXB annotated POJO
The below JSON response is obtained when we fire a GET HTTP request. The tool being used here is Postman
Similarly, the XML response can also be observed by simply toggling the AcceptĀ HTTP header to application/xml
Letās see a case where in we try to āpostā a representation of our domain object (XML/JSON) over the wire
Fire POST request via Postman
Snippet for the STDOUT in the server logs (as perĀ code above)
So, we just saw, in JAXRS, domain objects decorated with JAXB annotations allows can beĀ exchanged over the wire in both XML and JSON formats without breaking a sweat!
Consider a scenario where we already have rich domain Java objects available to us. But
- We do not have access to the source code
- We cannot really annotate them with JAXB annotations
- The domain entities are legacy POJOs which are not JAXB compatible
Here is where we can leverage customized content handling feature available in JAX-RS 2.0. The MessageBodyWriter and MessageBodyReader interfaces provide us a way to plug in our customized marshalling/unmarshalling mechanism and allow the JAX-RS run time to take care of the rest!
- The example which follows primarily deals with XML and JSON formats, but please note that these interfaces can be used for āanyā data formats ā the internet is teeming with hundreds of these with new ones popping up daily!
Letās see some code. . . . againā¦..
To begin with, in order to simulate a get scenario, letās just returnĀ an instance of a Legacy POJO class from our JAXRS resource method. Itās not JAXB compatible/we do not have the source code to decorate it via JAXB annotations
How do you think this will get serialized to XML over the wire? Our custom implementation of theĀ javax.ws.rs.ext.MessageBodyWriter interface will facilitate this.
This interface has 3 abstract methods which one would need to implement. The snippet showcases theĀ writeTo() method, which contains the bulk of the transformation logic.
- You can read about it further in theĀ Java EE 7 javadocs
So, as usual, we ask Postman to validate things for us, and this is what he had to say. No hassles! Imagine ifĀ the Legacy POJO representation is fetched from the persistent (DB) store directly ā all you need to do is return it since the on-the-wire representation has been taken care of
Now, the reverse scenario ā post an XML representation from our client layer and watch it getting serialized into the Legacy POJO instance. Want to persist it ? Sure, go ahead and fire the Entity Manager!Ā (donāt forgetĀ @javax.ejb.Stateless !)
How do you think the XML payload sent by the client getĀ convertedĀ to our Leagcy POJO instanceĀ over the wire? Our custom implementation of theĀ javax.ws.rs.ext.MessageBodyReaderĀ interface will makeĀ this happen.
Call upon Postman, post an XML representation over the wire, and see the results
Just to ensure that our Legacy POJO indeed got serialized ā confirmed via the server STDOUT logs
So, with the help of a trivial example, we saw how easy it is for us to defineĀ custom transformation/wrapper-like logic for handling custom domain objects/entities/POJOs within JAXRS based implementations.
Couple of observations before signing off
- JAXRS implementation in GlassFish4 does not support seamless JSON serialization/deserialization via a JAXB decorated POJO. Wildfly 8 worked like a charm! Kudos!
- On delegation of the marshall/unmarshall process to entity interceptors (reader/writer implementations), the seamless JSON support ceased to work (both in GlassFish as well as Wildfly). Not sure why. I am guessing the the JAXRS implementation is directly fetching the payload from/writing payload to the Input/Output streams respectively, and somehow there is no intermediate layer to factor in the content negotiation
I hope I am not missing a trick here! If you think so, please be kind enough to give me a heads up!
Well, thatās it for now! Happy codingā¦ā¦ā¦ā¦!
| Reference: | JAX-RS 2.0 : Custom Content Handling from our JCG partner Abhishek Gupta at the Object Oriented.. blog. |

















