If you’re familiar with Mulesoft products, then you probably already heard about our vision around APIs, our Anypoint API Manager solution and all our RAML based stories. Those are our recommended way of approaching REST APIs and if you haven’t already, we all highly recommend you to take a look at them. However, we’re about connecting everything, everywhere. Thus we recognize that there are a lot of APIs out there built in plain old Java code and a migration process is not something you can do overnight. If you own such an API, this post is about us wanting to help you too. Anypoint Platform includes a Jersey module to allow embedding Jersey-based APIs into the runtime, reusing the Java code powering your API but still gaining access to all the other features of the platform. In Mule 3.6 we upgraded our supported Jersey version from 1.6 to v2.11 to give you access to the latest and greatest that Jersey has to offer.
A little bit about Jersey
Jersey is the reference implementation for the JAX-RS specification about RESTful services in Java. In their own words: “Jersey framework is more than the JAX-RS Reference Implementation. Jersey provides it’s own API that extend the JAX-RS toolkit with additional features and utilities to further simplify RESTful service and client development. Jersey also exposes numerous extension SPIs so that developers may extend Jersey to best suit their needs.”
For more information on Jersey and access to its user guide, you can visit their website following this link.
A quick tour
For those of you not really familiar with our Jersey support, here’re a couple of quick examples on how you can use it. First, you declare a flow starting with an http inbound endpoint and then passing on control to the Jersey component:
The HelloWorldResource would look something like this:
You can also declare your own custom context resolvers:
Your own exception mappers:
You can even use interface bindings to invoke your very own Mule flows from your Jersey resource in a completely decoupled way!
So what’s new?
For starters, you now have access to the features in Jersey 2.0 and the JAX-RS 2.0 specification. Notice that if you want to update an existent API build using Jersey 1.x, this might require you to perform some code changes since the latest JAX-RS and Jersey are not backwards compatible with the 1.x versions.
There’re also some new features from the Mule namespace as well!
Your own properties
Now you can execute each resource passing your own set of server properties. For example, the following configuration specifies its very own set of language mappings:
Auto discover your extensions
Jersey is the proud owner of a very extensible Java API to allow developers modify almost every aspect of its inner working. A very popular request has always been to allow this from the Mule configuration. Because Jersey provides so many extension points, we choose to enable this using auto discovery capabilities. Per Jersey’s own API, every class annotated with the @Provider annotation can be used as an extension point. From the Mule namespace, we now allow specifying a list of java packages to scan for classes with such annotation. Every discovered class will be automatically registered in the resource’s context.
Here’s an example of how to register your own JAXB body writers and readers for an hypothetical Person class:
Here the packages com.my.project.jersey.readers and com.my.project.jersey.writers are being scanned and, for example, the following providers would be discovered:
With this upgrade we hope to continue supporting as many API scenarios as possible. Hopefully, this will enable you to combine the goodies of Jersey and the Java APIs with the power of the AnyPoint platform. Nevertheless, you may want to consider trying out the Anypoint Platform for APIs in order to get a next generation experience in designing, exposing, managing and consuming your APIs.