Registering Resources and Providers in Jersey 2

There has been some confusion on StackOverflow lately about how to register JAX-RS resource classes and custom providers in Jersey 2. The main problem seemed to be finding and using correct properties and methods to configure a JAX-RS/Jersey application. In this article I’d like to discuss 3 ways how to configure such an application properly.

Biggest difference between Jersey 1 and Jersey 2 in this regard is used namespace. Jersey 1 uses prefix com.sun.jersey (even for property names) which is not true for the namespace of Jersey 2 that starts with org.glassfish.jersey. Besides that Jersey 2 does NOT support properties from Jersey 1 and you need to use specific ones (from Jersey 2) to make things work.

Let’s assume I am working on a Jersey 2 application and I already have some resource classes and providers. What I want to do is to register my custom ContainerRequestFilter called SecurityRequestFilter that is responsible for setting correct SecurityContext for incoming requests. Since I am still developing my application I’d also like to see and log communication (incl. request/response entity) between client/server and be able to trace my requests if needed. For logging purposes I can use proprietary filter from Jersey called LoggingFilter. As mentioned I’d like to log the entity as well so I need to provide an instance of this filter created using the following constructor: LoggingFilter(Logger logger, boolean printEntity). Tracing support can be turned on by setting special property called ServerProperties.TRACING.

You can find a lot of other useful properties in *Properties classes like:
CommonPropertiesServerProperties or ClientProperties.

To register my providers I can use one of these approaches:

Application (JAX-RS)

Application defines the components of a JAX-RS application and supplies additional meta-data. With this approach you’re supposed to register everything (resource classes, providers, properties) the application will need:

ResourceConfig (Jersey specific)

ResourceConfig is itself an extension of JAX-RS Application class but it provides some convenience methods to make registering resources and providers more friendly:

web.xml (JAX-RS & Jersey specific)

Web application descriptor allows you to define JAX-RS Application (JAX-RS spec) for non Servlet 3.0 apps (you can use it with Servlet 3.0 as well but in Servlet 3.0 it’s enough to have an Application subclass on your class-path) or define contex-param/init-param for package-scanning, properties, …

Further reading

Deploying a RESTful Web Service
JAX-RS Application, Resources and Sub-Resources

  • Pingback: Binding JAX-RS Providers to Resource Methods | tl;dr()

  • Pingback: Handling JAX-RS and Bean Validation Errors with MVC | tl;dr()

  • Mehdi

    Great article.
    However, what’s the purpose of the Application class to register resources if we still register them on the web.xml file ??
    p.s : resources registration in web.xml works for me, but not the one in Application / ResourceConfig classes.
    Thank you.

    • Michal Gajdos

      Registering resources/providers via JAX-RS Application is a standard (JAX-RS) way how to deploy an app. ResourceConfig is just more convenient (and more powerful) than JAX-RS Application. Registering resources/providers via web.xml is specific to JAX-RS implementation (in our case it’s specific to Jersey).

  • Mehdi

    Thank you for your post.
    What do you mean by : “in Servlet 3.0 it’s enough to have an Application subclass on your class-path”
    because in my case I’m using Servlet 3.0 but I can’t just find WHY do I get 404 errors when my resources are registered on the Application / ResourceConfig subclass;
    Thank you.

    • Michal Gajdos

      In Servlet 3+ environment the only thing you need to deploy (instead of some resources :) ) a Jersey application is JAX-RS Application subclass (or Jersey ResourceConfig subclass). Application/ResourceConfig is found via class-path scanning.
      Note, that you also need jersey-container-servlet module on your class-path. This module makes sure that the Jersey/JAX-RS app is found and deployed.

      • Mehdi

        Thanks!

  • Vijay Kumar Rajput

    Thanks for this article. Can you please explain what is LOGGER attribute in register(new LoggingFilter(LOGGER, true));

  • Pingback: How can I get resource annotations in a Jersey 2.4 filter? | Zeminski Answers()

  • Pingback: Jersey Response Filter | Zahradnik Answers()

  • Binh Thanh Nguyen

    Thanks, nice post

  • Thank you.

  • Paul Newport

    Looks like the API has changed since this article was written – getSingletons is now final so you can’t override it. Any idea how you should amend the code for Jeresy 2.14 ?

    • Michal Gajdos

      Method getSingletons() is final only in ResourceConfig. You can use register(singleton) call in a constructor of extension of ResourceConfig instead. However, getSingletons() method in Application class (from JAX-RS) can still be overridden.

      • Paul Newport

        Thanks, ended up doing it the way you suggested above anyway. Quite a big change from v1 to v2 of the API, good job our code has lots of unit tests to help us through the upgrade process!