Jersey 1.0.3 is released

We have just released version 1.0.3 of Jersey, the open source, production quality, reference implementation of the JAX-RS 1.0 API. The JAX-RS specification is available at the JCP web site and also available in non-normative HTML here.

It will be available soon from the Glassfish v2 and v3 update centers.

To get started with Jersey read the getting started document. For an overview of JAX-RS features read the Jersey user guide. To understand more about what Jersey depends on read the dependencies document.

The following JavaDoc is available:

  • Client, Server, Grizzly, WADL, JSON APIs.
  • Spring integration API.
  • Guice integration API.
  • MIME Multipart API.
  • Client using Apache HTTP client API.
  • Atom with Apache Abdera API.
  • Simple HTTP server integration API.

This release has many bug fixes, you can see the change log here, as well as the following improvements and features:

    • Guice 2.0 integration, leveraging the contribution by Gili Tzabari. Guice integration is on a par with Spring integration.
      The support depends on Guice 2.0 distributed in the GuiceyFruit maven repository. GuiceyFruit, developed by James Strachan, is a set of extensions to Guice 2.0, such as support for Java EE artifacts like @PostConstruct/@PreDestroy, @Resource and @PersistenceContext. Jersey combined with GuiceyFruit makes for a very interesting fruity combination.
    • Developer defined WADL-based resource classes, inspired by James Strachan's use of WADL and Jersey MVC.
      Injecting WadlApplicationContext enables access to the WADL JAXB representation for the application.
    • Multipart MIME improvements to the jersey-multipart module.
      The parsing of Multipart MIME now uses the MIMEPull API which provides efficient stream-based processing and the caching of large MIME body parts to disk. Thus very large Multipart MIME may be consumed without running out of memory (as was previously the case).
      The overloaded use of @FormParam with "multipart/form-data" body parts has now been deprecated as this caused much confusion and created an artificial and limited abstraction when processing form data. This has been replaced with @FormDataParam.
      Finally Imran M Yousuf provided a number of useful fixes, tests and improvements, such as client-side uploading files with FileDataBodyPart.
    • Niall Gallagher contributed container support for the Simple HTTP server. This was an excellent contribution, code, tests and documentation, very easy to integrate.
    • Enterprise session beans as resource classes.
      Ken and I worked on integration with the latest builds of Glassfish as described here.
    • Client API listeners when producing/consuming representations.
      Pavel added support via a filter to listen to the client sending and receiving representations, which is useful to present feedback when uploading or downloading files. See ConnectionListenerFilter.
    • Plug-in Java type support for @\*Param annotations.
      JAX-RS defines a set of rules (for example, see @QueryParam) but it is useful to support additional rules.
      The JAX-RS rules are implemented using StringReaderProvider and developers may implement the same provider interface to add their own rules. Jersey provides support for java.util.Date (using the standard HTTP supported date formats) and JAXB for XML-encoded documents.
    • Pavel has added a sample showing how to use Jersey with HTTPs, client certificates and Grizzly.
    • Jakub has created the maven infrastructure for a Jersey user guide (also available in PDF). Currently the user guide contains the JAX-RS overview (the same as presented on the Jersey wiki) and documentation on JSON support.
      Documentation is important (and as one person said to me, no documentation, no feature) but it takes time for us developers to write English prose, so the user guide will be developed iteratively. Contributions to this area are most welcome.
    • Naresh's Jersey test framework has been included and some samples are already using it. We plan to transition over the other samples and may make breaking changes to the test API as we improve support.

    The next release, 1.1.0-ea, is scheduled for the end of April 2009. This will be an early access implementation of the JAX-RS 1.1 maintenance release. We will be calling it "early access" because not all EE features will be ready until the full EE 6 implementation is available in the final release GlassFish v3. However, developers can still expect the same degree of quality as that for previous releases of Jersey.

    For feedback send email to: (archived here)

    or log a bugs/features here.



    >Developer defined WADL-based resource classes, inspired by James Strachan's use of WADL and Jersey MVC.
    Injecting WadlApplicationContext enables access to the WADL JAXB representation for the application.

    Is there a sample that demonstrates the generation of a WADL that includes the XSD of JAX-B annotated entities? Is it possible to generate a WADL outside of having to deploy the web-app and visit URI: http://host:port/<resource-base>/application.wadl ??

    Posted by Mark Rabick on April 17, 2009 at 11:05 AM CEST #

    I recently wrote a blog entry [1] on WADL support in Jersey 1.0.3 and it has a working example which might provide some information you are looking for.



    Posted by Arul on April 17, 2009 at 11:10 PM CEST #

    See also:

    Posted by Paul Sandoz on April 20, 2009 at 03:59 AM CEST #

    Paul, I'm trying jersey 1.0.3 with json, numbers are serialized with double quotes ?

    Posted by Tony Nys on April 30, 2009 at 11:03 AM CEST #

    Hi Tony,

    Can you send email to:

    or log an issue:

    Please include an example so we can reproduce the problem.


    Posted by Paul Sandoz on April 30, 2009 at 11:10 AM CEST #

    Hi Paul,

    I am new to REST and WADL stuff and I started using jersey for one of my projects. (jersey-1.1.1.ea-snapshot)

    I came across lot of articles on wadl particulary using yahoo search api as an example. I understood how to generate client stubs using wadl and wadl2java. But I am not able to understand how a WebApplicationException gets converted to fault element in WADL?

    For e.g, I have a very simple resource namely Project and it throws EntityNotFoundException (a subclass of WebApplicationException) . what is the process involved in representing this exception as a fault element in WADL?

    I took the following steps:

    Created the Resource 'Project'
    Created the Exception 'EntityNotFoundException' (subclass of WAE)

    Used schemagen to generate corresponding xsd's
    Used wadl-generator to generate wadl from those xsds.

    However the generated wadl does not contain fault elements like the ones in yahoo search API.

    Could you please help me figure how to create those fault elements in wadl ? is it a manual process?

    Thanks in advance

    Posted by krishna on June 03, 2009 at 01:51 PM CEST #

    @krishna: See here for response:

    Posted by Paul Sandoz on June 05, 2009 at 06:16 PM CEST #

    Post a Comment:
    • HTML Syntax: NOT allowed



    « June 2016