Jersey 2.6 has been Released: New and Noteworthy

As some of you may have already noticed, we’ve recently released Jersey 2.6 (Reference Implementation of JAX-RS – Java API for RESTful Web Services). In this article I’d like to introduce some of the new features, important bug fixes and other noteworthy changes.

Jersey 2.6.x is the latest version of Jersey targeted to JDK 6. Refer to Latest Jersey Versions to find out the latest version that supports JDK 7/8.

Injections into Client Provider Instances

In some cases you might need to inject some custom types into your client provider instances. JAX-RS types do not need to be injected as they are passed as arguments into API methods. Injections into client providers (filters, interceptor) are possible as long as the provider is registered as a class. If the provider is registered as an instance then runtime will not inject the provider. The reason is that this provider instance might be registered into multiple client configurations. For example one instance of ClientRequestFilter can be registered to two Clients.

To solve injection of a custom type into a client provider instance use ServiceLocatorClientProvider to extract ServiceLocator which can return the required injection. The following example shows how to utilize ServiceLocatorClientProvider:

For more information see javadoc of ServiceLocatorClientProvider (and javadoc of ServiceLocatorProvider which supports common JAX-RS components).

Repackaged Guava and ASM

Jersey, from versions 2.6 for JAX-RS 2.0 and 1.18.1 for JAX-RS 1.1, no longer transitively brings Guava and ASM libraries to your application. This means that even when we still use them internally you can use different versions of these libraries. Classes from both of these libraries has been repackaged, and jersey.repackaged.objectweb.asm respectively, and shrinked to lower the footprint. ASM 5 is now part of jersey-server core module and for Guava we’ve created a separate bundle module jersey-guava as this dependency is widely used in multiple Jersey modules.

Transparent PATCH Support Example

Marek created http-patch example based on a very nice Gerard‘s blog-post Transparent PATCH support in JAX-RS 2.0. The example demonstrates how to implement generic support for HTTP PATCH Method (RFC-5789) via JAX-RS reader interceptor (see PATCH, resource and interceptor). The patch format supported by the example is JSON Patch (RFC-6902).

The example contains one resource that represents a patchable state, which consists of 3 properties:

  • a title text property,
  • a message text property, and
  • a list property that represents a list/array of text strings.

The default state in JSON format looks like:

This state can be patched via HTTP PATCH method by sending the desired patch/diff in the JSON Patch format as defined in RFC-6902, for example:

And the result:

Defining Entity Filtering output Fields via Query Parameters

Andy enhanced our Entity Filtering feature with an option to define output fields of a bean dynamically via query parameters. Suppose you have a JAXB bean like:

And you only need streetAddress and region on your client. By registering SelectableEntityFilteringFeature it’s possible to define these fields in a query parameter (supported in comma delimited “dot notation” style). For example, the following URL

will do the magic:

For more information about Selectable Entity Filtering refer to our documentation and entity-filtering-selectable example.

Using Custom ObjectMapper in Jackson 2.x Providers

Jersey provides support for Jackson 1.x JSON providers via a separate media module jersey-media-json-jackson. For Jackson 2.x we don’t need any special module at the moment because Jackson 2.x JSON providers are registered automatically when they’re present on the class-path of JAX-RS application (see jackson-jaxrs-providers). Due to a bug in previous versions of Jersey 2.x it wasn’t possible to pass an ObjectMapper instance to message body readers and writers via ContextResolver mechanism:

Thanks to Jakub the bug has been fixed and you can configure and use Jackson 2.x providers without any issues.

Jersey Libraries in WARs deployed on a CDI-enabled Container

When deploying a Jersey (< 2.6) application with Jersey bits bundled in the web-app archive (WAR) on a container with enabled CDI (i.e. GlassFish) you can run into a bunch of exceptions. These exceptions are trying to tell you that some of the (CDI) dependencies couldn’t be satisfied. The rationale behind this is that every class present in the WAR that uses @Inject annotation are considered to be a CDI bean which needs to be resolved immediately. Even before our dependency injection framework, HK2, has a chance to say whether it can satisfy the injection point instead of CDI.

Fortunately, via implementing the Extension contract, it’s possible to let the CDI know that it should ignore certain classes so you can handle these injection points by yourself somewhere else.

Fixing this issue brings a nice little “side-effect” about which I’ll write another blog post (soon).

Declarative Linking has been Migrated from Jersey 1.x

Thanks to Gerard the “declarative linking” feature has been migrated from Jersey 1.x into Jersey 2.x and is available in our incubator in declarative-linking module.

Release Notes

To see the complete list of changes and bug-fixes refer to Jersey 2.6 Release Notes.