Monday Mar 16, 2015

Jersey 2.17 Has Been Released

We have just released the 2.17 version of Jersey, the open source, production quality, reference implementation of JAX-RS 2.0.

To download Jersey 2.17, please check out our download page.

You can also check out the refreshed Jersey 2.17 documentation:

This version includes mainly bug fixes. Following is a list of the most important updates:

Tuesday Mar 03, 2015

When to Use JAX-RS Class-path Scanning Mechanism

The short answer is: never!. I have seen several nasty (so called) "bugs" caused by this feature so that i felt like sharing this little advice via blog post:

Never ever use JAX-RS class-path scanning feature in a production environment

Class-path scanning looks like a handy feature. Let say you do not want bother with enumerating all the components you would like to include in your JAX-RS application. Then your JAX-RS application class could look like:

import javax.ws.rs.ApplicationPath;
import javax.ws.rs.core.Application;

@ApplicationPath("rest")
public class EasyToConfigureJaxRsApplication extends Application {
}

The above example works great. When started, the application just scans the actual class-path, and adds every single JAX-RS component class found there to the actual runtime configuration. Isn't is great? Frankly, this kind of configuration could work just fine. Until someone changes either the system configuration (system class-path) or the way how you application is being packaged (a new 3rd party component could be added/removed from the application class-path then). These changes could be out of your control and if one of them happens, you application configuration could break. For this reason, it is not wise to use this kind of configuration in a production environment.

One could think that for development purposes, using this cool feature would be fine. I think otherwise. You either develop an application targeted for production use, and then you want to stick with whatever will be used in production eventually (where class-path scanning is a no-go) or you just want to look around and play with things. In the latter case you still want to keep control and avoid any nasty surprise.

To end up in a positive way. Here is another advise: Should you need to use any kind of scanning (for any reason), check out Jersey package scanning feature that allows you to control the scope of scanning. See the following links for some more details: https://jersey.java.net/apidocs/latest/jersey/org/glassfish/jersey/server/ResourceConfig.html#packages(java.lang.String...), https://jersey.java.net/apidocs/latest/jersey/org/glassfish/jersey/server/ServerProperties.html#PROVIDER_PACKAGES

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.

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-Oracle

Search

Archives
« July 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