Tuesday Mar 24, 2015

What to do when JAX-RS cannot find it’s Providers aka My message body writer is not used

One of the reasons why I wrote this article is my, rather unusual, encounter with a missing message body writer in a Jersey 1 test application. This problem of mine occurred during collecting of data to get a Jersey 1 performance baseline in order to see where Jersey 2 stands when compared to its predecessor. The problem is described at the end of this article because I think it’s pretty rare, but still not impossible :-), and not many of you will (hopefully) face it. But first I’d like to take a look at more common issues regarding missing providers and what you can do to solve them.

More in my original post on blog.dejavu.sk 

Tuesday Mar 17, 2015

JAX-RS Providers on Client and on Server

In this article I'd like to explain two things. First, what to do when you want to restrict JAX-RS providers to be used on, for example, client-side only. And second, what are the issues (and how to solve them) with injecting providers when you create and register instances of them directly.

Constraining JAX-RS providers to particular runtime

Some of the JAX-RS providers can be used on the server-side as well as on the client-side. The reusability of providers was among the goals when JAX-RS 2.0 Client API was proposed and designed. Unquestionably this being a useful feature of JAX-RS 2.0 there are cases in which you want to constrain some of the available providers to either client or server. Constraining providers, or Features for that matter, is even more useful when writing a general purpose library that aims to support both sides but each in a slightly different manner.

More in my original post on blog.dejavu.sk 

Wednesday Mar 11, 2015

Jersey CDI Integration – Few Notes and EAR Support

During our last sprint I was porting support for CDI injections for EARs that contain multiple JAX-RS web applications (WARs). This worked fine in Jersey 1 and it works on WebLogic but we didn't have support for these kind of deployments directly in Jersey (which means that Glassfish was affected as well) until this very moment. I'd like to share some findings I've made while working on this task.

See my original post on blog.dejavu.sk 

Friday Mar 06, 2015

Checkstyle matters to Jersey too …

Last week Pavel wrote and published an interesting blog post about Why Checkstyle matters … I remember how he was describing his encounter with JeroMQ to me. Especially the part where he wasn’t able to build the project for a few times because of the Checkstyle issues that pop-up right after he executed the build. I found the whole idea behind running code style checks during build appealing as well and decided to do something similar for Jersey.

See my original post on blog.dejavu.sk 

Thursday Jan 24, 2013

Jersey 1.17 is released

We have released the 1.17 version of Jersey, the open source, production quality, reference implementation of JAX-RS. The JAX-RS 1.1 specification is available at the JCP web site and also available in non-normative HTML here.

For an overview of JAX-RS features read the Jersey user guide. To get started with Jersey read the getting started section of that guide. To understand more about what Jersey depends on read the dependencies section of that guide. See change log here.

Here is the list of notable changes (versions 1.13-1.17):


  • added support for notifying ResponseListener implementations about thrown unmapped application exceptions (see ResponseListener#onError) (JERSEY-1642)
  • fixed the hardcoded package in project created using the jersey-quickstart-grizzly2 archetype (JERSEY-1618)
  • accepted contribution by Arul Dhesiaseelan - Simple Server version update (4.1.20 -> 5.0.4) (JERSEY-1641)


  • HTTPBasicAuthFilter/HTTPDigestAuthFilter constructors allowing you to avoid storing plain password value in a String variable (support for passwords represented as byte[]) (JERSEY-1601)
  • fix for OPTIONS call to a webservice method with a leading "/" in @Path annotation
  • accepted contribution by Gerard Davison - Automatic JSON-Schema Generation (for more information on this topic take a look at this blog post)


  • enabled InputStream parameter to be set on a WADL generator (JERSEY-1409)
  • Multipart.BodyPart now allows setting headers other than those starting with Content-* (JERSEY-1448)
  • applied the patch from Charlie Groves to unwrap WebApplicationException from the Guice ProvisionException (JERSEY-1386)


  • fix for getting file name from the content disposition header of multi-part messages sent by Internet Explorer (JERSEY-759)
  • support for package scanning (resource & provider discovery in WAR archives) in OSGi environment (JERSEY-881)
  • WADL: Matrix params generation moved to "resource" element to not violate WADL spec (JERSEY-1336)
  • added property to WadlGeneratorGrammarsSupport which controls whether Jersey generated grammars should be used when user explicitly sets its own grammar (JERSEY-1230)


  • support for retrieving services defined in META-INF/services for Jersey extensions (oauth, multipart, ...) that has other version as used Jersey Core module. (JERSEY-1124)
  • added Vary header in GZIPContentEncodingFilter (JERSEY-1228)
  • added ResourceContext binding to Guice (JERSEY-1219)
  • extracting Form parameters when consumed by filters enabled for POST, PUT and other methods as well (JERSEY-1200)
  • added SubjectSecurityContext to enable subject-based security
  • JSON support refactored + support for MOXy as JAXB provider

For feedback send email to:

users@jersey.java.net (archived here)

or log bugs/features here.


Mirror of blog.dejavu.sk


« July 2016