Skip to end of metadata
Go to start of metadata

Welcome to the Community Wiki for Project Jersey!

Project Jersey is an open source community that is building the production quality reference implementation of JSR-311: JAX-RS - Java API for RESTful Web Services. Jersey implements support for the annotations defined in JSR-311, making it easy for developers to build RESTful web services with Java and the Java JVM. Besides implementing the JSR-311 API, Jersey provides an additional API not specified by JSR-311 so that developers can extend this JSR to suit their specific needs. This wiki contains information for the developers using Jersey, for the developers improving Jersey, and for the people with a general interest in RESTful Web Services.

We hope that you will find the Jersey Wiki to be a valuable informational resource. We actively encourage you to become a contributor and share your knowledge about Jersey and RESTful Web Services with the rest of the open source community. Contributors to existing or new wiki topics only need to have a registered user id and some knowledge they'd like to share.

If you're new to Jersey and/or RESTful Web Services, and are unable to find the information you need on this wiki page, please leave us a comment and we'll do our best to find the answer and add it to the wiki so that it will be available to all.

What are RESTful Web Services?

RESTful Web services are services that are built to work best on the Web.

Representational State Transfer (REST) is an architectural style that specifies constraints, such as the uniform interface, that if applied to a Web service induce desirable properties, such as performance, scalability and modifiability, that enable services to work best on the Web.

In the REST architectural style, data and functionality are considered resources, and these resources are accessed using Uniform Resource Identifiers (URIs), typically links on the web. The resources are acted upon by using a set of simple, well-defined operations. The REST architectural style constraints an architecture to a client-server architecture, and is designed to use a stateless communication protocol, typically HTTP. In the REST architecture style, clients and servers exchange representations of resources using a standardized interface and protocol. These principles encourages RESTful applications to be simple, lightweight, and have high performance.

To find out more about REST, try these sources for more information:

Get Started

  1. Read the getting started document on how to develop your first simple JAX-RS application with Jersey.
  2. Read the JAX-RS Overview of JAX-RS 1.0 Features for many details of the JAX-RS API and deployment using Jersey.
  3. Read the dependencies document to understand how to use Jersey with maven and the Java.Net maven repository.
  4. Check out the samples that ship with Jersey. For more info on the examples, see the section below.
  5. Read the blogs (referenced below) or read the Jersey FAQ for information on more advanced topics.
  6. Read the Jersey Tutorial, also known as the RESTful Web Services Developers Guide. This tutorial contains the following topics:
    1. Chapter 1: Introduction to RESTful Web Services and Jersey
    2. Chapter 2: Installing Jersey and the Jersey Sample Applicatons
    3. Chapter 3: Creating a RESTful Resource Class
    4. Chapter 4: Creating, Deploying, and Running Jersey Applications
    5. Chapter 5: Jersey Sample Applications
  7. Follow the Jersey Hands-On Lab

Learn More

Example Applications

The sample applications, which are listed below, can be downloaded here.

  • HelloWorld: This is how everybody starts using Grizzly as in the process HTTP server.
  • HelloWorld Web app: This is how everybody starts using a Web application.
  • Bookmark Web app: Demonstrates how to use JPA in the backend.
  • Bookstore Web app: Demonstrates how to use polymorphism with resources and views that are JSP pages.
  • EntityProvider: Demonstrates pluggable entity providers.
  • Extended WADL Web app:Demonstrates how to customize generation of WADL.
  • Generate WADL: Demonstrates how to customize generation of WADL.
  • Jaxb: Demonstrates the use of JAXB-based resources.
  • JMaki-backend Web app: Provides JSON to be consumed by jMaki widgets.
  • JsonFromJaxb: Demonstrates how to use JSON representation of JAXB-based resources.
  • Mandel: A Mandelbrot service written in Scala using Scala's actors to scale-up the calculation.
  • OptimisticConcurrency: Demonstrates the application of optimistic concurrency to a web resource.
  • SimpleAtomServer:Simple Atom server that partially conforms to the Atom Publishing Format and Protocol.
  • SimpleConsole: Demonstrates a simple service using Grizzly.
  • SimpleServlet: Demonstrates how to use a Servlet container.
  • Sparklines: A sparklines application inspired by Joe Gregorio's python application.
  • Spring annotations: An example leveraging Jersey's Spring-based annotation support.
  • StorageService: Demonstrates a basic in-memory web storage service.

Here are a few other examples. Please add any others to the list that you find useful.

General Information

  • Schedule - Planned features and Jersey release dates

For Jersey Users

  • External Links - Links to articles and blogs containing samples and hints for using Jersey
  • WADL - What does jersey provide related to WADL and how this can be used

For Jersey Developers

What are Folks from the Open Source Community Saying About JAX-RS and Jersey?

basics basics Delete
web web Delete
design design Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Oct 16, 2007

    An example page with links would be nice, e.g.:

    1. Jun 13, 2008

      My apologies for the very late reply. I have added a link to the getting started page on the Jersey page.

  2. Jun 10, 2008

    There should be a clearly visible list of base requirements either here or on a separate page (FAQ?)

    ie. JavaSE6, Servlet 2.3 etc...

    1. Jun 13, 2008

      I have added a "What are the dependencies to the FAQ"

  3. Oct 01, 2008

    I commend the ease of which the examples can be quickly tried, using the built-in lightweight http server or NB project. But what about people who are not using NetBeans and wish to deploy it in some other configuration (stand-alone WAR, WAR inside an EAR where all the libs are part of the EAR libs.. etc)

    I've been finding it quite difficult actually to find any concrete information on what kind of setup is required in the web.xml to accomplish my needs (none of the info I have found has come from the Jersey docs, site or Wiki)

    Maybe the examples should contain dual distributions (one to run stand-alone through the Main class w/ built-in lightweight http, and one that builds a standard WAR that should be able to be deployed on any EE5 container [note: that does not require usage of the build\-impl.xml from the nbproject])

    1. Oct 02, 2008

      From your description i suspect that you are using an older distribution before we switched over to using Maven.

      Have you see the following sample:

      If you build this then a war is created you can deploy in an app server. There are a number of web-based samples provided.

      I have also just written this (as part of a larger overview document):

      Does this help?

  4. Jan 07, 2009

    Need help for running Bookmark sample using Netbeans & Glassfish V2/V3.
    Thanks in advance !

    1. Jan 08, 2009

      @Junfeng: the bookmark example works only with GlassFish V2. You should be able to simply run it from NetBeans6.5,
      if you have a GFv2 instance registered at your NetBeans as it works for me now (using the trunk version of the example). I am not sure about a need to manually configure the jdbc connection pool using the GFv3 admin interface, so if your NB complains during deployment, please look at the example's README.html doc and configure jdbc before you try to redeploy.

      1. Jan 08, 2009

        Thanks a lot, Jakub.
        Before I guessed GFv3 had Jersey plugin, and GFv2 didn't.

  5. Apr 05, 2009

    I have been using jersey for the past two weeks and am pretty excited about it's use in my project. Having said that, there is one area where I'm stumbling - and could not find a satisfactory answer searching the wiki. Basically I need to modify my generated xml (from the annotated JAXB pojo's which are consumed by JAX-RS servlet) to include a processing instruction like <xsl-stylesheet>.

    In JAXB, it's possible (using the marshaller object), but since I don't have access to it, I was wondering if there's a way I can somehow inject that in the generated xml.

    Thanks, and sorry if this is not the right place for this question - I didn't find a forum for asking question. If there is, feel free to move it there.



    1. Apr 06, 2009

      Hi Jalpesh,

      See here:

      If you need more help please email:


      1. Apr 07, 2009

        Thanks Paul,

        I think that resolved my issue. I'm hitting another error right now, but that's with using the SpringServlet. I'll email the above mentioned address with the error.

        --- Jalpesh.

  6. Apr 17, 2009

    I've been looking for a jersey forum where I can ask question and didn't find it, is there one ?

    1. Apr 20, 2009

      Send email to:

      you can use Nabble forum if you wish:


  7. Nov 02, 2009

    As usual, client-side samples get short shrift. I just want to write a simple backend client of someone else's RESTful Web Service. I'm sure I can dig it up but a sample would be nice.

    1. Nov 03, 2009

      Many of the samples have unit tests that utilize the Client API and are designed to show how that API can be used:

      Also see the following white paper:

      And see Jakub's example:

      If you have any questions send email to


  8. Aug 12, 2010

    Reading jersey documentation, I would expect that a client application would be a proxy for a server class, something like:

    public class MyClient {
    public String sayHello(String salutation) {
    //call to some jersey engine function
    MyClient c = ...
    String result = c.sayHello("good mordinig");

    But as far as i've read, you will always end up writing code like:

    WebResource.Builder builder = createWebResourceBuilder(UriBuilder
    .path(URL + "myserPerson.class);vice?method=sayHello& param1=good%20morning").build((Object[]) null));
    result = builder.get(String.class);

    That is, you have to build by hand all the http methods required for your application.

    In many places it's said that once you build a web service it's easy to reuse the same classes to create a client application.

    But it seems to me that we save just the 'signature' of this server classes, and we have to re-code all web-server access logic.

    Am I missing something?

    thanks in advance

    1. Aug 14, 2010

      You make the following call once:

      From then on you can do:

      So, basically it is what you would expect. One of the REST constraints is that there is a unified set of operations - applying REST to web, these are the HTTP operations such as GET, PUT, DELETE, POST. So, dynamically generating proxies is not necessary - WebResource already has all the necessary methods (get, put, post, delete) corresponding to this fixed set of HTTP operations you can perform on a resource.
      If you have further questions, please send e-mail to

  9. Feb 18, 2011

    Pretty much all the links into the oracle documentation site are bad.

    1. Feb 18, 2011

      Oh, thanks for catching this! Now it should be fixed.

      1. Feb 18, 2011

        Nice, thanks for the quick reply.

  10. May 11, 2011

    I'm evaluating Jersey framework and its test framework (using embedded lightweight Grizzly). How a developer can enable e.g. HTTP Digest authentication using Java (on test code) on embedded containers (like lightweight Grizzly, or other if applicable)?

    1. May 11, 2011

      Hello gsande,

      Jersey test framework currently don't have the ability to set security details (I guess we could support it, feel free to file new RFE). Problem with this is, that containers we currently support do not have special support for security. Additionally, settings for security stuff might get really complicated (certificate realms for example). What you can do is start and deploy your sevice by yourself and run test using jersey-test-framework-external module.

      You can take a look at https-clientserver-grizzly sample ( where we do test security on top of grizzly, but not using jersey test framework.

      if you need more detail or if you have additional questions, please use mailing list.


  11. May 17, 2011

    For the example jersey-samples-1.6\json-from-jaxb, when I run the maven command, mvn clean compile exec:java, this error occurs:

    [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project json-from-jaxb: Compilation failure

    [ERROR] Failure executing javac, but could not parse the error:
    [ERROR] javac: invalid flag: -s

    1. May 17, 2011

      Hello rieman,

      you need to use JDK 1.6+ (set JAVA_HOME property pointing to your JDK 1.6 installation directory).


  12. Sep 23, 2011

    Hey guys,

    I recently noticed that Jersey is AWESOME! I want to realize the following (REST service): -> XML output -> JSON output

    Is there a way to retrieve the GET parameter out while initializing the application and have it available in the controllers? In my controller method I would be able to do the following:

    I was thinking about the following: (is it possible?)

    • get the out parameter in the main application and set it as a static property of MyAbstractController
    • let all controller extend MyAbstractController

    I just found no way to realize the first point.

    Thanks in advance!!!

  13. Sep 24, 2011

    And another topic - slashes.

    Running an easy setup like ...

    Calling works.
    Calling results in an Not Found error (running with Google App Engine).

    Anyone an idea?

  14. Jan 06, 2012

    In order to get the Hello World example running ( you need to include 'grizzly-framework-2.1.2.jar' on the class path if you are not using maven. Otherwise the following error will result.

    Exception in thread "main" java.lang.NoClassDefFoundError: org/glassfish/grizzly/Grizzly
        at org.glassfish.grizzly.http.server.HttpHandler.<clinit>(
        at com.sun.jersey.server.impl.container.grizzly2.GrizzlyContainerProvider.createContainer    

    This jar file was not included in the list of jars 'Non-maven developers require:'

    1. Jan 06, 2012

      Filed to track fix for this issue.

  15. Feb 10, 2012


    I need your help to resolve couple of classloader issues. Currently I'm developing the Jersey+Spring based application from scratch.

    Here are the version details,

    Jersey 1.11
    Spring 3.1.0
    Websphere 6.1
    java 1.5

    Following jars are used.

    jackson-core-asl-1.9.2 and related jars

    5.RELEASE, web, beans, context, context-support ... jars

    I tried following combinations,

    Jersey 1.8 with Spring 3.0.5
    Jersey 1.8 with Spring 3.1.0
    Jersey 1.11 with Spring 3.0.5
    Jersey 1.11 with Spring 3.1.0

    Getting following issues,

    [2/10/12 17:40:40:372 EST] 000000ba WebExtensionP E   Error occured while preparing the servlet for initialization.
    java.lang.Exception: java.lang.LinkageError: LinkageError while defining class: com.sun.jersey.spi.spring.container.servlet.SpringServlet
    Could not be defined due to: (com/sun/jersey/spi/spring/container/servlet/SpringServlet) bad major version at offset=6
    This is often caused by having a class defined at multiple
    locations within the classloader hierarchy.  Other potential causes
    include compiling against an older or newer version of the class
    that has an incompatible method signature.
    Dumping the current context classloader hierarchy:
        ==> indicates defining classloader
       Local ClassPath: ...
       Delegation Mode: PARENT_FIRST
       [1] Local Classpath:  Delegation mode: PARENT_FIRST
       [4] org.eclipse.osgi.framework.adaptor.core.CDSBundleClassLoader@d7c0d7c
       [5] sun.misc.Launcher$AppClassLoader@6f4a6f4a
       [6] sun.misc.Launcher$ExtClassLoader@4340434
    --Original exception--
    java.lang.UnsupportedClassVersionError: (com/sun/jersey/spi/spring/container/servlet/SpringServlet) bad major version at offset=6

    also getting
    Could not be defined due to: (javax/ws/rs/Path) bad major version at offset=6
    This is often caused by having a class defined at multiple
    locations within the classloader hierarchy.  Other potential causes
    include compiling against an older or newer version of the class
    that has an incompatible method signature.
    Dumping the current context classloader hierarchy:
        ==> indicates defining classloader
       Local ClassPath: ......
       Delegation Mode: PARENT_FIRST
       [1] Local Classpath:  Delegation mode: PARENT_FIRST
       [4] org.eclipse.osgi.framework.adaptor.core.CDSBundleClassLoader@d7c0d7c
       [5] sun.misc.Launcher$AppClassLoader@6f4a6f4a
       [6] sun.misc.Launcher$ExtClassLoader@4340434
    --Original exception--
    java.lang.UnsupportedClassVersionError: (javax/ws/rs/Path) bad major version at offset=6


  16. May 22, 2012

    Hi, I am trying ti execute RestFul services on IBM Process server and using updated Jersey jars 1.12 version and getting following exception:"Error 404: REST Service Gateway: /rest/hello", in the console getting following error: ServletWrappe E   [Servlet Error]-[com.sun.jersy.spi.container.servlet.ServletContainer]: java.lang.ClassNotFoundException: com.sun.jersy.spi.container.servlet.ServletContainer

    as i have added com.sun.jersy.spi.container.servlet.ServletContainer in web.xml file.

    Please do the needful.

    Thanks in advance.



Sign up or Log in to add a comment or watch this page.

The individuals who post here are part of the extended Oracle community and they might not be employed or in any way formally affiliated with Oracle. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Oracle nor any other party necessarily agrees with them.