Jersey 1.0 is released

We have just released version 1.0 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.

To get started with Jersey read the getting started document. For an overview of JAX-RS features visit the Jersey wiki and read the overview document. To understand more about what Jersey depends on read the dependencies document. For details of the Jersey API go to here.

Jersey 1.0 is released to the Java.Net maven repository. Jars, source, JavaDoc and samples are all available from the following base URI:

All the samples can be obtained individually or as one zip file.

Jersey will be available soon from the Glassfish v2 and v3 update centers. And will be available in the Netbeans 6.5 release.

I decided to forgo a cycling themed picture this time and instead present a Castell. To quote Eduardo: "Many people need to do their tasks very well to build such a big castell". While the JAX-RS and Jersey castells may not require as many people as Glassfish i think the analogy still applies. Perhaps one could view Glassfish as an Escher like castell where each component is a castell itself? in any case i digress!

I would like to thank everyone that has contributed to the JAX-RS API and/or Jersey, whether it be the expert group members, comments on JAX-RS from external individuals (emails and blogs) and the many developers living on the edge trying out the Jersey early access releases, providing feedback and contributing code.

We have a better API because of the JCP process. With at least five different implementations of JAX-RS in development, four of them open source as of writing, the API was tested early and often.

We have a better reference implementation because we are open source, released early and often, and are responsive to the community.

What's next? In terms of JAX-RS the expert group will be starting a maintenance release to align with EE 6. In terms of Jersey here are some current aspects off the top of my head:

  • improve the boundaries between Jersey modules (for OSGi) and further modularize, this will require name changes to some API packages;
  • better MIME multipart support;
  • investigate further comet/AJAX integraton; and
  • improve the integration with IoC frameworks. It is hard to be abstract from any IoC framework.

there is much more and i plan to create a more complete set of short and long term tasks in the next couple of weeks. If you have ideas send email to:

or log a feature here.


[Trackback] Bookmarked your post over at Blog!

Posted by jersey on October 13, 2008 at 11:05 AM CEST #

Congratulations! I know you and the Jersey team worked very hard on this release and all of us in the community appreciate your dedication and quick and friendly responses!

Posted by Aaron Anderson on October 13, 2008 at 04:30 PM CEST #

I second Aaron's sentiments. Though I'm fairly new to Jersey, I really do like it. :)

Regarding Netbeans integration, I'm using Netbeans 6.1, where the "RESTful Web Services" plugin is based on Jersey 0.8. Is the only way to get 1.0 to use Netbeans 6.5, which is beta? The Netbeans 6.1 plugin will never be updated?

I assume I could create a project and add the Jersey 1.0 jars etc., but won't that confuse the 0.8 based plugin? Can I deactivate or delete the plugin, and then work that way? I assume the IDE integration won't be there, but at least I can use Jersey 1.0.



Posted by Jeff Schmidt on October 13, 2008 at 10:45 PM CEST #

@Araron, @Jeff, thanks very much for the kind feedback.

Re: NetBeans. I don't know if NB 6.1 will have plugin support for Jersey 1.0, i will check. The only way to currently get the latest plugin bits is via the NB 6.5 development builds.

You can modify a dependent NB project to use the Jersey 1.0 artifacts in your library settings. However, there have been API changes from 0.8 to 1.0 and the NB 6.1 plugin will be affected by those changes (e.g. @ProduceMime in 0.8 is now @Produces in 1.0).

Posted by Paul Sandoz on October 14, 2008 at 01:51 AM CEST #

I also want to thank you and the whole team for the tremendous work you did! Concrats!

And thanks for all the quick and friendly responses of course. I started using Jersey January this year and is has been very exciting to watch the progress and dynamics in this project. Cool stuff!


Posted by Ben on October 15, 2008 at 07:26 PM CEST #

Are there any documents anywhere to help out with transitioning an app from 0.9 to 1.0? Any significant API changes?


Posted by Clark on October 16, 2008 at 01:03 PM CEST #

Hi Clark,

See here:\*checkout\*/jersey/trunk/jersey/changes.txt

it includes all changes related to JAX-RS and Jersey between releases.

Posted by Paul Sandoz on October 16, 2008 at 01:32 PM CEST #

Client.create() seems expensive, is it good idea to have a client pool in application?


Posted by Hugo on October 22, 2008 at 11:36 PM CEST #

@Hugo: yes Client.create() is expensive.

Client is thread safe, as is WebResource. You only require one Client instance per-configuration. So having the client re-use an instance rather than creating one each time is best.

In terms of sharing the problem is the state of a Client instance can be modified e.g. adding filters, setting properties/features. Perhaps Client should be immutable and state changes result in a new instance?

Posted by Paul Sandoz on October 23, 2008 at 12:39 AM CEST #

Hi Paul,

Thanks for your quick response. I am trying to resolve the following issue:

Let's say I have 3 web service providers: A (SLA:100ms), B (SLA:10ms), C (SLA:100ms).

A and B can be called in parallel, but C has to wait for B's response.
In order to set different timeout for each backend, i will call:

Because timeout may be different for each backend, I have to create a client instance for each?


Posted by Hugo on October 23, 2008 at 01:23 AM CEST #

Ah, i see now. Yes, currently you do, which is not good :-(

It would be better to allow for properties to be set on WebResource, which would override any set on Client.

Fortunately properties are associated with the request so it does not appear to be complicated to support this.

And.. there is a work around. Do not set the properties on the Client, define a ClientFilter implementaton that adds properties to the request as follows:

public class TimeFilter implements ClientFilter {
public TimeFilter(int x, int y) { ... }
public ClientResponse handle(ClientRequest cr)
throws ClientHandlerException {
cr.getProperties().put(ClientConfig.PROPERTY_CONNECT_TIMEOUT, x
cr.getProperties().put(ClientConfig.PROPERTY_READ_TIMEOUT, y
return getNext().handle(request);;

WebResource r = c.resource(...);
r.addFilter(new TimeFilter(10, 10));

Could you log an issue?

It seems useful to have some polices associated with URIs and something could look up the properties associated with the policies. Thus you don't have to hard code the time out values. Perhaps as a filter, or your own WebResource factory?


Posted by Paul Sandoz on October 23, 2008 at 01:50 AM CEST #

I found a bug from Jersey 1.0. if using any method to request a resource and that the result will be forward to a JSP file,
then found that all the value setted to the response object will be lost. after check the source code found problem as bellow:

Source code from "com.sun.jersey.impl.application.WebApplicationImpl" in handleRequest method

public void handleRequest(ContainerRequest request, ContainerResponseWriter responseWriter)
throws IOException {
final ContainerResponse response = new ContainerResponse(
handleRequest(request, response);

as above we see that HttpServletResponse is wrapped by the ContainerResponseWriter object. for invoking method of
" public void handleRequest(ContainerRequest request, ContainerResponse response) throws IOException " ContainerResponse wraps the
ContainerResponseWriter again.
so here I found the problem that the value setted in ContainerResponse object not save back to orginal HttpServletRequest..

finally it cause to com.sun.jersey.impl.container.servlet.JSPTemplateProcessor 's method named "writeTo" can only get a unchaged HttpServletResponse instance.

public void writeTo(String resolvedPath, Object model, OutputStream out) throws IOException {
RequestDispatcher d = servletContext.getRequestDispatcher(resolvedPath);
if (d == null) {
throw new ContainerException("No request dispatcher for: " + resolvedPath);

d = new RequestDispatcherWrapper(d, ui.getMatchedResources().get(0), model);

try {
// Matt mark here. actually the HttpServletResponse get from current thread object is unchanged.
d.forward(requestInvoker.get(), responseInvoker.get());
} catch (Exception e) {
throw new ContainerException(e);

Here I add one line code to solve this problem

public void handleRequest(ContainerRequest request, ContainerResponse response) throws IOException {
try {
final WebApplicationContext localContext = new
WebApplicationContext(this, request, response);


try {
for (ContainerResponseFilter f : responseFilters)
response = f.filter(request, response);

} catch (WebApplicationException e) {
mapWebApplicationException(e, response);
} catch (RuntimeException e) {
if (!mapException(e, response)) {
throw e;
//matt add here
//before write method save the response header value back to store HttpServletResoponse object
response.getContainerResponseWriter().writeStatusAndHeaders(-1, response);

try {
} catch (WebApplicationException e) {
if (response.isCommitted()) {
throw e;
} else {
mapWebApplicationException(e, response);
} finally {

Your reply is expecting!

Posted by Matthew Xie on October 30, 2008 at 03:24 AM CET #

Hi Matthew,

Thanks for reporting the bug. I fixed it in the trunk.

I replied to your email sent to the Jersey users list [1]. Note that users list is configured such that replying does not include the original sender, i am guessing you are not subscribed to the list :-)



Posted by Paul Sandoz on October 30, 2008 at 03:49 AM CET #

Post a Comment:
  • HTML Syntax: NOT allowed



« July 2016