Friday Feb 13, 2015

Container Agnostic CDI Support In Jersey

Introduction

At the time of this writing, Java SE support is being discussed as one of important additions to CDI 2.0 specification. Existing CDI implementations brought this feature already, only container bootstrapping has not yet been standardized. In Jersey version 2.15 we introduced Weld SE support, so that people could take advantage of CDI features also when running in Java SE environment. As part of this work, the old Jersey CDI module has been refactored so that it supports CDI integration in any CDI-enabled HTTP container.

Containers Known to Work With Jersey CDI Support

To stick with JAX-RS specification, Jersey has to support JAX-RS/CDI integration in Java EE environment. The two containers supporting JAX-RS/CDI integration out of the box are Oracle GlassFish and Oracle WebLogic application server.

Apache Tomcat is another Servlet container that is known to work fine with Jersey CDI support. However, things do not work there out of the box. You need to enable CDI support in Tomcat e.g. using Weld. Jersey CDI example shows how a WAR application could be packaged (see tomcat-packaging profile in the pom file) in order to enable JAX-RS/CDI integration in Tomcat with Jersey using Weld.

Another Servlet container that is supported by Weld is Jetty. Jersey CDI integration module should work there as well, but things have not been tested by Jersey team.

If not bundled already with underlying Servlet container, the following Jersey module needs to be packaged with the application or otherwise included in the container class-path:

<dependency>
    <groupId>org.glassfish.jersey.ext.cdi</groupId>
    <artifactId>jersey-cdi1x</artifactId>
    <version>2.16-SNAPSHOT</version>
</dependency>
            

Request Scope Binding

There is a common pattern for all above mentioned containers. Jersey CDI integration builds upon existing CDI/Servlet integration there. In other words, in all above cases, Jersey application must be deployed as a Servlet, where the underlying Servlet container has CDI integrated already and CDI container bootstrapped properly.

The key feature in CDI/Servlet integration is proper request scope binding. If this feature was missing, you would not be able to use any request scoped CDI beans in your Jersey application. To make Jersey work with CDI in containers that do not have request scope binding resolved, some extra work is required.

To allow smooth integration with Jersey request scope a new SPI, ExternalRequestScope, was introduced in Jersey version 2.15. An SPI implementation should be registered via the standard META-INF/services mechanism and needs to make sure CDI implentation request scope has been properly managed and request scoped data kept in the right context. For performance reasons, at most a single external request scope provider is allowed by Jersey runtime.

Jersey Weld SE Support

The extra work to align HTTP request with CDI request scope was already done by Jersey team for Weld 2.x implementation. In order to utilize Jersey/Weld request scope binding, you need to use the following module:

<dependency>
    <groupId>org.glassfish.jersey.ext.cdi</groupId>
    <artifactId>jersey-weld2-se</artifactId>
    <version>2.16-SNAPSHOT</version>
</dependency>
            

Then you could use your CDI backed JAX-RS components in a Jersey application running in Grizzly HTTP container bootstrapped as follows:

Example Bootstrapping Jersey application with Weld support on Grizzly

            Weld weld = new Weld();
            weld.initialize();

            final HttpServer server = GrizzlyHttpServerFactory.createHttpServer(URI.create("http://localhost:8080/weld/"), jerseyResourceConfig);

            // ...

            server.shutdownNow();
            weld.shutdown();

The above pattern could be applied also for other Jersey supported HTTP containers as long as you stick with CDI Weld 2.x implementation. You simply add the above mentioned jersey-weld2-se module into you class-path and bootstrap the Weld contatiner manually before starting the HTTP container.

Thursday Feb 12, 2015

Jersey 2 Performance

During my sabbatical week in January i have done some performance improvements in Jersey server core module. These changes are already included in Jersey version 2.16.

To make sure the changes indeed made a positive difference i have re-established continuous performance testing for Jersey server side processing. These automated tests allowed Michal Gajdoš to collect some numbers that show how performance evolved within Jersey 2.x version space. In this post i would like to share part of the outcome of this measurement. I hope to be able to reveal more numbers and details on the test setup in later posts.

The above graph shows how Jersey throughput increased with increased Jersey version. Version 2.4 is emphasised here as till that version we had a serious bottleneck in Jersey, that avoided throughput to scale with increased number of worker threads.

The above numbers capture increased throughput for regular resource methods handling plain text payload, where no sub-resource locators are involved. Sub-resource locators used to have poor throughput in Jersey versions prior to 2.16. In 2.16 Michal fixed this and i would recommend you check out his post on this topic here.

I think that the above graph clearly shows that we take performance seriously in Jersey. I hope that we will be able to further improve performance of Jersey in future versions.

Friday Jan 30, 2015

Jersey 2.x Client on Android

Jersey Client has been enabled for Android devices. This post describes what has been done in the recent Jersey snapshot version, how basic things were tested in Android environment, and what to do next.[Read More]

Friday Jun 29, 2012

Jersey 2.0 Integrated into GlassFish 4.0

The latest promoted build of GlassFish 4.0 (glassfish-4.0-b43.zip) now contains upgraded Jersey version, 2.0-m05. Users are getting an early access to the implementation of some parts of the JAX-RS 2.0 API Early Draft Review 3. The appropriate JAX-RS bundle, version 2.0-m09 , gets bundled into GlassFish 4.0 as well.

What should work

The simple answer is: all the basic stuff. We have particularly tested the following two examples: Both above linked archives contain adjusted projects, so that resulting war files do not bundle any Jersey dependencies. Both also use Jersey 2 specific Servlet class, org.glassfish.jersey.servlet.ServletContainer, for deployment. See Martin's blog post on how to package war applications capable of running with both Jersey 1 and Jersey 2 ServletContainer classes.

What has not been covered yet

The main areas, which have not been touched yet in Jersey 2 are:
  • EJB integration
  • CDI integration
  • Validation
These are also the areas where we are going to spend the most of our cycles in the coming month.

Wednesday Feb 22, 2012

Jersey 1.12 is released

We have just released the 1.12 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.

This version includes mainly bug fixes. The biggest update is Jersey asynchronous client switched internally from using Netty to Grizzly 2 client implementation. Grizzly 2 dependency was upgraded to version 2.2.1.

For feedback send email to:

users@jersey.java.net (archived here)

or log bugs/features here.

Besides 1.12, we have been working hard on our first public milestone for Jersey 2.0 and I am happy to let you know we have released that as well - see Marek's blog post for more details. As a result, Jersey 1.x releases may become less regular and we don't expect to add any bigger features going forward, as Jersey 2.0 becomes our main focus. We are planning to add some new exciting stuff there in the following months, so stay tuned!

Tuesday Dec 13, 2011

Jersey 1.11 is released

Yesterday, we have released the 1.11 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.

The main addition in 1.11 is integrated EclipseLink MOXy support. An interesting, external binding, feature there allows you to use unannotated POJOs as JAXB beans for XML processing. This could be quite handy when you deal with external, 3rd party provided, beans without having control on it's source code. Checkout Jersey's moxy-oxm-mapping example readme file to see how to utilize this new feature in Jersey.

Another major addition, added by Pavel, is the ability to attach filters to non-blocking clients.

Besides the above, we managed to do some bug fixing and Jon spent some time on docs cleanup.

For feedback send email to:

users@jersey.java.net (archived here)

or log bugs/features here.

About

Jakub Podlesak

Search

Archives
« March 2015
SunMonTueWedThuFriSat
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
    
       
Today