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 Feb 27, 2015

Jersey Monthly Newsletter – February 2015

Jersey team has become more active in writing blog posts so I’ve decided to give it a try and publish a short summary of these posts and maybe something more at the end of each month. This first post focuses heavily on Jersey but I’d like to include interesting articles from more sources about the world of JAX-RS and REST services in the next months.

At the beginning I’d like to mention a page where you can always find information about the latest released Jersey 1.x and 2.x. This includes links to the release notes, API docs, user guide and a blog post related to that release. It’s called Latest Jersey Versions and it is available on this very site.

But lets get into more interesting stuff. One of the goals we had in our Jersey sprints in February was performance. Articles Jersey 2 Performance and Performance Improvements of Sub-Resource Locators in Jersey dive into the details what we did to improve performance in version 2.16 and provide comparison with older versions as well. We also prepared a set of tools to run benchmarks with your own JAX-RS (server/client) applications – they are described in Micro-Benchmarking JAX-RS Applications. Nobody’s perfect and we (our injection framework) had some memory leaks when an application was deployed on a servlet container like Tomcat/Jetty. Adam has been investigating this and he wrote a short article about finding memory leaks in Jersey applications on Tomcat. You can find it here – One Funny Thing Not to Forget While Profiling on Tomcat.

More in my original post on blog.dejavu.sk 

Thursday Feb 19, 2015

Micro-Benchmarking JAX-RS Applications

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.

Benchmarks I am going to focus on are based on JMH tool from JDK. If you’ve never encountered JMH I highly recommend and encourage you to go through their samples which will show you the main features of the tool. In under 30 minutes you’ll be able to write your own benchmarks.

But lets get back to JAX-RS and Jersey – the main goal of bringing the support for micro-benchmarks was to measure the values (e.g. throughput) as precisely as possible for both, server and client, without any unnecessary interferences.

We’ve introduced a new module, jersey-test-framework-util, with some handy utilities to write your own benchmarks. The module is already available in the workspace and in some time it’s going to be also in Jersey 2.17.

More in my original post on blog.dejavu.sk 


Mirror of blog.dejavu.sk


« July 2016