Embed Apache Johnzon in your library to not depend on a dependency

Sometimes you need to parse JSON files in a library. Then the question is pretty quickly: do I use a SPI (Service Provider Interface) to let the user choose the library he uses with my code or do I bind my library to one parser/writer?

Sometimes the answer is easy: when the need is basic (read/write) having a SPI and a default implementation is pretty good and let your users avoid to depend on one implementation. Said otherwise, you let your users reuse the implementation they probably already have in their application/classpath.

However sometimes you need a more advanced setup to get some customizations or features (like comments in JSON for instance which is very handy for configuration files) so either you bind your library to one implementation and your users end with N JSON implementations they don’t control and which potentially conflict together, or you enhance a lot your SPI risking to loose some features if your user chooses an implementation not supporting some of your needs, or you can also grab an implementation which work fine for you and just put it in your delivery. This last option is pretty nice cause then your code can use all the shortcuts an implementation can offer – like custom annotations.

Going further with this last option you can also potentially reuse some standard API like JSON-P or the coming JSON-B in your code and just hide it and not depend on the container for the runtime.

Of course there is no free lunch and it will make your delivery a bit more heavy but a good mapper is ~200k max so it is still a good option for JSON needs.

How to do it?

Apache Johnzon JSON library and Javascript date

By default Apache Johnzon JSON-Java mapper uses the pattern “yyyyMMddHHmmssZ” for Dates. The good thing about this pattern is that it is fast enough for most cases. However, its drawback is not as common as the ISO8601 format of the RFC822.

The solution is quite simple.

JSON and WebSocket: Johnzon to the rescue

When writing a WebSocket endpoint the first thing you do is to create the endpoint (connection point) then you have to define the protocol to use. Because of what is modern IT world it is quite common to use JSon as payload format for WebSocket messages. Of course you can use any JSon mapper you want or JSON-P directly but you can actually go a bit further and that is what does Johnzon in its coming 0.8-incubating release.

JSon for configuration: Apache Johnzon made another step with comments

Using JSon for a configuration file is very tempting but there is a big drawback: you can’t comment anything with a strict JSon parser.

This is something which is blocking for a configuration IMO because you often need to explain why you configured something in the way it is.

Apache Johnzon: more configuration and TomEE integration

Apache Johnzon is an implementation of JSON-P specification but it also includes
a JSON java mapper and a JAX-RS provider.

First version was not very easy to configure (actually it was but it needed to extend
default implementation) but since 0.2-incubating it is designed to work out of the box.

It was done adding a new class: org.apache.johnzon.jaxrs.ConfigurableJohnzonProvider
and a bunch of setters (+ lazy initialization of the mapper).

Here a sample to integrate it with TomEE resources.xml (but using Spring or any other configuration
model should work as well while setters are supported):

<Service id="johnzon" class-name="org.apache.johnzon.jaxrs.ConfigurableJohnzonProvider">
    ignores = com.foo.MyType,com.foo.MyOtherType
    accessMode = method
    supportHiddenAccess = true
    doCloseOnStreams = false
    version = 2
    skipNull = true
    skipEmptyArray = true
</Service>

Then to use it in TomEE just like it as usual in openejb-jar.xml:

<?xml version="1.0" encoding="UTF-8"?>
<openejb-jar xmlns="http://www.openejb.org/openejb-jar/1.1">
  <pojo-deployment class-name="jaxrs-application">
    <properties>
      cxf.jaxrs.providers = johnzon

      # this one is not mandatory but recommanded
      cxf.jaxrs.skip-provider-scanning = true
    </properties>
  </pojo-deployment>
</openejb-jar>

Side note: didn’t dig into it but using tomee service references ($refName)
you can even configure in resources.xml the Johnzon Mapper directly and just
set it (mapper attribute) in JohnzonProvider…but this is less intuitive then.

This way if default configuration (Pojo) doesn’t fit your need cause you use private constructors, field mapping etc… you can customize it pretty easily now.

Last but nice: default Johnzon provider is the one used out of the box in TomEE 2 for json serialization!