Jersey 0.5 is released


We have just released version 0.5 of Jersey (see the stable download directory). This aligns with the 0.5 release of the JAX-RS API and the latest editors draft.

This version will be available soon from the Glassfish Update Centre and as part of the NetBeans RESTful Web service plugin from the NetBeans Beta Update Centre.

This release has improved the deployment and configuration process. The annoying pre-compile step is gone, which means no need to modify build configuration scripts. It is now a very simple process. For example, using Grizzly:

SelectorThread s = GrizzlyServerFactory.create("http://locahost:9090/");

Or the Light Weight HTTP server:

HttpServer s = HttpServerFactory.create("http://localhost:9090/");

Or using standard elements in a web.xml file for Web applications deployed using Glassfish (or other compliant Servlet containers):


Underneath the covers, thanks to Frank's ASM code, Jersey will efficiently scan Java class files present in the java.class.path for Grizzly and the Light Weight HTTP server or in the WEB-INF/classes and WEB-INF/lib for Web applications. This mechanism is extensible so it is possible to plug in a different discovery mechanism. Jersey also comes with an implementation to scan Java class files given a set of package names, which can be configured for a Web application as follows:


A recent comment on Marc's blog entry about Jersey Spring integration showed how this could be achieved for Spring for resource classes present in the Spring context.

WADL generation is improved and is generated dynamically (no configuration is required), as described here and here.

The URI dispatching architecture was completely re-written is much more flexible and pluggable. So we can easily adapt to changing requirements in the JAX-RS API in addition to Jersey specific requirements. For example, we integrated Frank's efficient URI matching algorithm as a component that kicks in when there are more than 8 URI path templates to be matched (that number can probably be reduced, but I was being conservative!). I am sure there is more innovation and performance improvements we can do here.

The Grizzly support was over-hauled and we moved to the most recent version, 1.7, thanks to JFA's help.

The examples have been converted to use NetBeans 6.0.

The next release, 0.6, is scheduled for March 7th, as show here, which lists a number of areas we plan to work on. There are three main goals for the 0.6 release:

  1. a high-level client-side API;

  2. a better component and life-cycle model for all JAX-RS related components; and

  3. model, view controller support with a pluggable template rendering.

I think these goals align well with feedback we have been getting about JAX-RS and Jersey. They are rather ambitious but we will try our best to get it all done!

As usual feedback and participation is most welcome, just send email to the users list and/or log issues.


Hi ! I'm the bloke who kept asking questions at your presentation this afternoon, and talked to you about OSGi. Very interesting presentation, BTW - even if I'm a bit biased, being keen on all things REST :-)

I'll try and make Jersey work as an OSGi bundle tonight, and keep you posted. I'll probably do a first version where all root resource classes have to be declared in a special manifest header in user bundles. Then I'll see if I can make the scanning work.

The caching you do inside Jersey might be an issue. How is that implemented ? Is it a static collection hidden somewhere ? It would be nice to know more about that.


Posted by Olivier Pernet on January 18, 2008 at 02:27 PM CET #

Hi Olivier,


Would you be willing to take this discussion over to the Jersey users list? I think that would be easier to manage and i am sure others on the list will be interested. You can subscribe here:

Re: to caching. I talk about it a bit in this blog entry:

I have tried to ensure that stuff is not cached in static fields but is scoped to non-static fields of a "Web application" instance. At a minimum we would need a way to reload a Web application and a mechanism to trigger that reload.


Posted by Paul Sandoz on January 21, 2008 at 08:14 AM CET #

[Trackback] The Grizzlet concept seems to attract enough attention those days to force me to update the current implementation. More important, I'm getting more and more requests to move the Grizzlet concept out of Grizzly and make it available for Jetty and Tomca...

Posted by Jean-Francois Arcand's Blog on February 14, 2008 at 07:04 PM CET #

Could you use Jetty in a similar way? Does anyone know if it will work. I'm having some problems.

When I start the Jetty server I get: contains no paths

I have passed in some init params.

Posted by Jon on March 06, 2008 at 04:50 AM CET #

Hi Jon,

I replied in general about Jetty to another comment you posted on the Spring blog.

Want to transfer the conversation over to:

? that way it is easier to track and others can contribute.

Others are using Jetty (maven-jetty-plugin jetty:run target) with the "PackagesResourceConfig" as the default class scanning does not work with Jetty in this deployment mode.

It sounds like from the description you are not using the package scanning configuration, is that correct? Or are you using the init-param set up presented in this blog?


Posted by Paul Sandoz on March 06, 2008 at 05:23 AM CET #

[Trackback] Happy Birthday Project Grizzly! One year has passed since we started the Grizzly Project by its own...from zero, we have now a strong community of users, customers and an healthy Grizzly that doesn't seems to want to hibernate!

Posted by Jean-Francois Arcand's Blog on March 13, 2008 at 08:17 PM CET #

Post a Comment:
  • HTML Syntax: NOT allowed



« July 2016