Jax Rs

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.

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.

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.

Sometimes you want to examine what impact would a new JAX-RS filter have on performance of your application. Whether your custom message body provider is as fast as you though or you simply want to find out the throughput of your JAX-RS resources or client instances. Recently we were looking into this area and we’ve created few utilities that may make your life easier if you want to write micro-benchmarks for JAX-RS applications.

There were many performance improvements since Jersey 2 first came out almost 2 years ago. Jakub and I decided to present some of the latest ones in our recent articles. Jakub took a look at general performance gains in Jersey in his Jersey 2 Performance. I’ll try to cover the change we introduced in Jersey 2.16 and that affected processing and performance of sub-resource locators in Jersey applications.

Yesterday I was given the opportunity to speak at our local Java User Group meeting (CZJUG). I was covering two topics – JAX-RS.next and Reactive Jersey Client. In this post I’d like to share the used slide-decks and some additional resources.

Although I am not a big fan of sending JSON in other places than in the message body as the entity, for example in query parameter in case of requests, it’s not a rare use-case and the way how it can be solved in JAX-RS 2.0 gives me a nice opportunity to illustrate usage of two new interfaces, ParamConverterProvider and ParamConverter. You can then re-use this approach to inject other media-types or formats your application relies on via @*Param annotations (@MatrixParam, @QueryParam, @PathParam, @CookieParam, @HeaderParam).

Few times I’ve ran into a situation in which I wanted to return only a part of entity I was working with, in my service, to the client-side. Feature that would allow me to send this partial set of fields should not only be driven by my own filtering rules but it also should take into consideration application roles the current user is in. It’s not an uncommon use-case I’d say so in Jersey we’d come up with the Entity Filtering concept that would allow you to do such a thing: sending subgraph of entities from server to client (and vice versa), define your own filtering rules and make sure users get only the fields they are supposed to see.

Since JAX-RS 2.0 you can use Bean Validation to validate inputs received from users and outputs created in your application. It’s a handy feature and in most cases it works great. But what if you’re using also MVC and you want to display custom error page if something goes wrong? Or what if you want to handle Bean Validation issues in a slightly different way than JAX-RS implementation you’re using does? This article will give you some answers to these questions.

Different life-cycles of Jersey 2 and GlassFish 4 arise a question how to make sure that ones GlassFish instance contains always the latest version of Jersey. This question is even more important in case you don’t want to download the nightly/promoted build every-time a new version of Jersey is released but you still want to use the latest and greatest Jersey.

Note: The script below is not compatible with Jersey 2.6 at the moment. I’ll update it as soon as possible.