Access Keys:
Skip to content (Access Key - 0)
Cancel    
Cancel   
 

Jersey Module Reference

Jan 20, 2015 07:37

Nicolas Earnshaw

Jan 20, 2015 07:37

Mulesoft Current Mule Documentation

Jersey Module Reference

Mulesoft Documentation Page

Contents

Jersey Module Reference

Jersey is a framework built over JAX-RS (JSR-311) implementation. JAX-RS is a specification that provides a series of annotations and classes which make it possible to build RESTful services. The Mule Jersey transport makes it possible to deploy these annotated classes inside Mule.

Our recommended approach to REST APIs is using RAML and exposing APIs through the Anypoint Platform for APIs. Jersey might still in some cases be the path of minimum resistance for when the API you want to expose was built in Java and lacks a RAML file that describes how to interface to it.

In addition to the annotation capabilities, Jersey contains many useful features:

  • The ability to integrate with XML data-binding frameworks such as JAXB
  • The ability to produce/consume JSON easily
  • The ability to integrate with the JSP presentation tier
  • Integration with Abdera for Atom support.

 

Mule 3.6 makes use of Jersey v2.11, whilst older versions of Mule used Jersey 1.6. If you want to update an existent API built using Jersey 1.x, this might require you to perform some code changes, since the latest JAX-RS and Jersey versions aren't backwards compatible with the 1.x versions.

Currently implicit views are not supported.

 Contents

 

Classpath Settings

The latest Jersey module uses Jersey v2.11

 

Writing a Service

Writing JAX-RS services is an expansive topic and will not be covered in this guide. However, the Jersey website has an excellent set of samples, and the JAX-RS specification is helpful as well.

We will, however, take a look at a simple hello world service. This example requires the installation of Apache Xalan JARs.

The first step to create a JAX-RS service is to create a class which represents your HTTP resource. In our case we'll create a "HelloWorldResource" class. Methods on this class will be called in response to GET/POST/DELETE/PUT invocations on specific URLs.

The @Path annotation allows you to bind a class/resource to a specific URL. In the sample below we're binding the HelloWorldResource class to the "/helloworld" URL.

Looking at the "sayHelloWithUri" method we see several annotations involved:

  • @POST specifies that this method is only called on @POST requests to the URL.
  • @Produces specifies that this method is producing a resource with a mime type of "text/plain".
  • @Path binds this method to the URL "/helloworld/{name}". The {name} is a URI template. Anything in this portion of the URL will be mapped to a URI parameter named "name" (see below)
  • @PathParam binds the first parameter of the method to the URI parameter in that path named "name".

Deploy the Web Service

Once you've written your service, you can create a jersey:resources component which contains a set of Jersey resources. URL. Below is a very simple configuration which does this:

Consume a RESTful Web Service

Once you run this configuration in Mule, you can hit the url: http://localhost:8080/jersey/helloworld/Dan and you should see this response in your browser: 'Hello Dan'.

 

 

Exception Mappers

It is possible to register exception mappers inside the resources element. Exception mappers allow mapping generic exceptions that may be thrown in the component class to HTTP response codes, you can add as many of these as you want.

The following configuration maps a HelloWorldException that may be thrown during the execution of HelloWorldResource to HTTP error 503 (Service Unavailable):


HelloWorldExceptionMapper.java

 

Context Resolvers

Context resolvers are injected into resource classes, and they provide context information to them, which can be useful in certain cases when you need specific metadata that is not available by default.

When you use JAXB for your XML/JSON serialisation, JAXB provides some annotations in case you would need to change the output format. A simple example of such annotations is @XmlElement where you can provide the name of the field as a property on the annotation itself: @XmlElement(name="PersonName").

Some configuration however is not possible to achieve using annotations. For example by default when using JAXB for JSON serialisation, the numbers (int, long ...) are surrounded by double quotes, making them look like strings. This might be good for some projects, but other projects might want to remove those double quotes. This can be done by configuring a ContextResolver on the Jersey resource. Let's take a quick example. If we have a class called Person which internally contains an age property, and we would want this Person object to be returned as a JSON object with the age without quotes, first create the custom context resolver.

CustomContextResolver.java

In the above CustomContextResolver, we are specifying that for class of type Person, we return a JAXBContext which is configured using JSONConfiguration class using the natural notation. Once we have our custom Jersey ContextResolver, we need to configure that in Mule.

Without the custom context resolver, the output would look like the following:

With the custom context resolver, the output changes to the following:

ContextResolvers can also be used to configure other XML/JSON libraries such as Jackson. The following is a custom context resolver to configure Jackson to return numbers in quotes.

 

"CustomJacksonContextResolver"

For more information about context resolvers, check out the Jersey user guide.


Sending a Jersey Response to Other Flows

 

You can use interface bindings to invoke completely separate Mule flows from your Jersey resource:

 

Adding Custom Properties

You can execute resources passing your own set of server properties. For example, the following configuration specifies its very own set of language mappings:

 

Extension Autodiscovery

Jersey owns a very extensible Java API that allows developers to modify almost every aspect of its inner working. Because Jersey provides so many extension points, these are exposed in Mule through auto discovery capabilities. Per Jersey’s own API, every class that you annotate with the @Provider annotation can be used as an extension point. A list of java packages that contain this annotation and exist in the mule namespace is shown, 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:

 

Go Further

For more information on how to use Jersey, see the project website.