JBoss.orgCommunity Documentation

Chapter 3. Installation/Configuration

3.1. RESTEasy modules in WildFly
3.1.1. Other RESTEasy modules
3.1.2. Upgrading RESTEasy within WildFly
3.2. Deploying a RESTEasy application to WildFly
3.3. Deploying to other servlet containers
3.3.1. Servlet 3.0 containers
3.3.2. Older servlet containers
3.4. Configuration
3.4.1. RESTEasy with MicroProfile Config
3.4.2. Using pure MicroProfile Config
3.4.3. Using RESTEasy's extension of MicroProfile Config
3.4.4. Configuring MicroProfile Config
3.4.5. RESTEasy's classic configuration mechanism
3.4.6. Overriding RESTEasy's configuration mechanism
3.5. Configuration switches
3.6. javax.ws.rs.core.Application
3.7. RESTEasy as a ServletContextListener
3.8. RESTEasy as a Servlet Filter
3.9. Client side

RESTEasy is installed and configured in different ways depending on which environment you are running in. If you are running in WildFly, RESTEasy is already bundled and integrated completely so there is very little you have to do. If you are running in a different environment, there is some manual installation and configuration you will have to do.

In WildFly, RESTEasy and the JAX-RS API are automatically loaded into your deployment's classpath if and only if you are deploying a JAX-RS application (as determined by the presence of JAX-RS annotations). However, only some RESTEasy features are automatically loaded. See Table 3.1. If you need any of those libraries which are not loaded automatically, you'll have to bring them in with a jboss-deployment-structure.xml file in the WEB-INF directory of your WAR file. Here's an example:

<jboss-deployment-structure>
    <deployment>
        <dependencies>
            <module name="org.jboss.resteasy.resteasy-jackson-provider" services="import"/>
        </dependencies>
    </deployment>
</jboss-deployment-structure>

The services attribute must be set to "import" for modules that have default providers in a META-INF/services/javax.ws.rs.ext.Providers file.

To get an idea of which RESTEasy modules are loaded by default when JAX-RS services are deployed, please see the table below, which refers to a recent WildFly ditribution patched with the current RESTEasy distribution. Clearly, future and unpatched WildFly distributions might differ a bit in terms of modules enabled by default, as the container actually controls this too.


RESTEasy is bundled with WildFly, but you may want to upgrade RESTEasy in WildFly to the latest version. The RESTEasy distribution comes with a zip file called resteasy-jboss-modules-4.7.3.Final.zip. Unzip this file within the modules/system/layers/base/ directory of the WildFly distribution. This will configure WildFly to use new versions of the modules listed in Section 3.1, “RESTEasy modules in WildFly”.

To build the resteasy-jboss-modules-4.7.3.Final.zip, enter the jboss-modules directory of the project, and run the following Maven command:

$ mvn install

It will start to build the modules and finally it will produce the zip file inside "target" directory:

$ pwd
resteasy/jboss-modules
$ ls target/*.zip
target/resteasy-jboss-modules-4.7.3.Final-mavenized.zip
target/resteasy-jboss-modules-4.7.3.Final.zip

To use the zip file, you need to copy it into Wildfly's "modules" directory:

$ pwd
wildfly
$ ls
LICENSE.txt       bin               domain            standalone
README.txt        copyright.txt     jboss-modules.jar welcome-content
appclient         docs              modules

Use the following step to copy and extract the modules zip into Wildfly modules directory:

$ cp ~/works/resteasy/jboss-modules/target/resteasy-jboss-modules-4.7.3.Final.zip \
modules/system/layers/base/
$ cd modules/system/layers/base
$ unzip resteasy-jboss-modules-4.7.3.Final.zip
...

With the above process, the RESTEasy modules are upgraded inside Wildfly.

RESTEasy is bundled with WildFly and completely integrated as per the requirements of Java EE. You can use it with EJB and CDI and you can rely completely on WildFly to scan for and deploy your JAX-RS services and providers. All you have to provide is your JAX-RS service and provider classes packaged within a WAR either as POJOs, CDI beans, or EJBs. A simple way to configure an application is by simply providing an empty web.xml file. You can of course deploy any custom servlet, filter or security constraint you want to within your web.xml, but none of them are required:

<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">
</web-app>

Also, web.xml can supply to RESTEasy init-params and context-params (see Section 3.5, “Configuration switches”) if you want to tweak or turn on/off any specific RESTEasy feature.

Since we're not using a <servlet-mapping> element, we must define a javax.ws.rs.core.Application class (see Section 3.6, “javax.ws.rs.core.Application”) that is annotated with the javax.ws.rs.ApplicationPath annotation. If you return any empty set for classes and singletons, which is the behavior inherited from Application, your WAR will be scanned for resource and provider classes as indicated by the presence of JAX-RS annotations.

import javax.ws.rs.ApplicationPath;
import javax.ws.rs.core.Application;

@ApplicationPath("/root-path")
public class MyApplication extends Application
{
}       

Note. Actually, if the application jar contains an Application class (or a subclass thereof) which is annotated with an ApplicationPath annotation, a web.xml file isn't even needed. Of course, even in this case it can be used to specify additional information such as context parameters. If there is an Application class but it doesn't have an @ApplicationPath annotation, then a web.xml file with at least a <servlet-mapping> element is required.

Note. As mentioned in Section 3.1.1, “Other RESTEasy modules”, not all RESTEasy modules are bundled with WildFly. For example, resteasy-fastinfoset-provider and resteasy-wadl are not included among the modules listed in Section 3.1, “RESTEasy modules in WildFly”. If you want to use them in your application, you can include them in your WAR as you would if you were deploying outside of WildFly. See Section 3.3, “Deploying to other servlet containers” for more information.

If you are using RESTEasy outside of WildFly, in a standalone servlet container like Tomcat or Jetty, for example, you will need to include the appropriate RESTEasy jars in your WAR file. You will need the core classes in the resteasy-jaxrs module, and you may need additional facilities like the resteasy-jaxb-provider module. We strongly suggest that you use Maven to build your WAR files as RESTEasy is split into a bunch of different modules:

<dependency>
    <groupId>org.jboss.resteasy</groupId>
    <artifactId>resteasy-core</artifactId>
    <version>4.7.3.Final</version>
</dependency>
<dependency>
    <groupId>org.jboss.resteasy</groupId>
    <artifactId>resteasy-jaxb-provider</artifactId>
    <version>4.7.3.Final</version>
</dependency>

You can see sample Maven projects in https://github.com/resteasy/resteasy-examples.

If you are not using Maven, you can include the necessary jars by hand. If you download RESTEasy (from http://resteasy.jboss.org/downloads.html, for example) you will get a file like resteasy-jaxrs-<version>-all.zip. If you unzip it you will see a lib/ directory that contains the libraries needed by RESTEasy. Copy these, as needed, into your /WEB-INF/lib directory. Place your JAX-RS annotated class resources and providers within one or more jars within /WEB-INF/lib or your raw class files within /WEB-INF/classes.

The resteasy-servlet-initializer artifact will not work in Servlet versions older than 3.0. You'll then have to manually declare the RESTEasy servlet in your WEB-INF/web.xml file of your WAR project, and you'll have to use an Application class (see Section 3.6, “javax.ws.rs.core.Application”) which explicitly lists resources and providers. For example:

<web-app>
    <display-name>Archetype Created Web Application</display-name>

    <servlet>
        <servlet-name>Resteasy</servlet-name>
        <servlet-class>
            org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher
        </servlet-class>
        <init-param>
            <param-name>javax.ws.rs.Application</param-name>
            <param-value>com.restfully.shop.services.ShoppingApplication</param-value>
        </init-param>
    </servlet>

    <servlet-mapping>
        <servlet-name>Resteasy</servlet-name>
        <url-pattern>/*</url-pattern>
    </servlet-mapping>

</web-app>

The RESTEasy servlet is responsible for initializing some basic components of RESTEasy.

Note. It is likely that support for pre-3.0 Servlet specifications will be deprecated and eliminated eventually.

RESTEasy has two mutually exclusive mechanisms for retrieving configuration parameters (see Section 3.5, “Configuration switches”). The classic mechanism depends on context-params and init-params in a web.xml file. Alternatively, the Eclipse MicroProfile Config project (https://github.com/eclipse/microprofile-config) provides a flexible parameter retrieval mechanism that RESTEasy will use if the necessary dependencies are available. See Section 3.4.4, “Configuring MicroProfile Config” for more about that. If they are not available, it will fall back to an extended form of the classic mechanism.

In the presence of the Eclipse MicroProfile Config API jar and an implementation of the API (see Section 3.4.4, “Configuring MicroProfile Config”), RESTEasy will use the facilities of MicroProfile Config for accessing configuration properties (see Section 3.5, “Configuration switches”). MicroProfile Config offers to both RESTEasy users and RESTEasy developers a great deal of flexibility in controlling runtime configuration.

In MicroProfile Config, a ConfigSource represents a Map<String, String> of property names to values, and a Config represents a sequence of ConfigSources, ordered by priority. The priority of a ConfigSource is given by an ordinal (represented by an int), with a higher value indicating a higher priority. For a given property name, the ConfigSources are searched in order until a value is found.

MicroProfile Config mandates the presence of the following ConfigSources:

  1. a ConfigSource based on System.getProperties() (ordinal = 400)
  2. a ConfigSource based on System.getenv() (ordinal = 300)
  3. a ConfigSource for each META-INF/microprofile-config.properties file on the ClassPath, separately configurable via a config_ordinal property inside each file (default ordinal = 100)

Note that a property which is found among the System properties and which is also in the System environment will be assigned the System property value because of the relative priorities of the ConfigSources.

The set of ConfigSources is extensible. For example, smallrye-config (https://github.com/smallrye/smallrye-config), the implementation of the MicroProfile Config specification currently used by RESTEasy, adds the following kinds of ConfigSources:

  1. PropertiesConfigSource creates a ConfigSource from a Java Properties object or a Map<String, String> object or a properties file (referenced by its URL) (default ordinal = 100).
  2. DirConfigSource creates a ConfigSource that will look into a directory where each file corresponds to a property (the file name is the property key and its textual content is the property value). This ConfigSource can be used to read configuration from Kubernetes ConfigMap (default ordinal = 100).
  3. ZkMicroProfileConfig creates a ConfigSourceConfigSource that is backed by Apache Zookeeper (ordinal = 150).

These can be registered programmatically by using an instance of ConfigProviderResolver:

Config config = new PropertiesConfigSource("file:/// ...");
ConfigProviderResolver.instance().registerConfig(config, getClass().getClassLoader());
        

where ConfigProviderResolver is part of the Eclipse API.

If the application is running in Wildfly, then Wildfly provides another set of ConfigSources, as described in the "MicroProfile Config Subsystem Configuration" section of the WildFly Admin guide (https://docs.wildfly.org/21/Admin_Guide.html#MicroProfile_Config_SmallRye).

Finally, RESTEasy automatically provides three more ConfigSources:

  • org.jboss.resteasy.microprofile.config.ServletConfigSource represents a servlet's <init-param>s from web.xml (ordinal = 60).
  • org.jboss.resteasy.microprofile.config.FilterConfigSource represents a filter's <init-param>s from web.xml (ordinal = 50). (See Section 3.8, “RESTEasy as a Servlet Filter” for more information.)
  • org.jboss.resteasy.microprofile.config.ServletContextConfigSource represents <context-param>s from web.xml (ordinal = 40).

Note. As stated by the MicroProfile Config specification, a special property config_ordinal can be set within any RESTEasy built-in ConfigSources. The default implementation of getOrdinal() will attempt to read this value. If found and a valid integer, the value will be used. Otherwise the respective default value will be used.

RESTEasy offers a general purpose parameter retrieval mechanism which incorporates MicroProfile Config if the necessary dependencies are available, and which falls back to an extended version of the classic RESTEasy mechanism (see Section 3.4.5, “RESTEasy's classic configuration mechanism”) otherwise.

Calling

ConfigurationFactory.getInstance().getConfiguration()
            

will return an instance of org.jboss.resteasy.spi.config.Configuration:

public interface Configuration {

    /**
     * Returns the resolved value for the specified type of the named property.
     *
     * @param name the name of the parameter
     * @param type the type to convert the value to
     * @param <T>  the property type
     *
     * @return the resolved optional value
     *
     * @throws IllegalArgumentException if the type is not supported
     */
    <T> Optional<T> getOptionalValue(String name, Class<T> type);

    /**
     * Returns the resolved value for the specified type of the named property.
     *
     * @param name the name of the parameter
     * @param type the type to convert the value to
     * @param <T>  the property type
     *
     * @return the resolved value
     *
     * @throws IllegalArgumentException         if the type is not supported
     * @throws java.util.NoSuchElementException if there is no property associated with the name
     */
    <T> T getValue(String name, Class<T> type);
}
            

For example,

String value = ConfigurationFactory.getInstance().getConfiguration().getOptionalValue("prop_name", String.class).orElse("d'oh");
        

If MicroProfile Config is available, that would be equivalent to

String value = ConfigProvider.getConfig().getOptionalValue("prop_name", String.class).orElse("d'oh");
        

If MicroProfile Config is not available, then an attempt is made to retrieve the parameter from the following sources:

  1. system variables, followed by
  2. environment variables, followed by
  3. web.xml parameters, as described in Section 3.4.5, “RESTEasy's classic configuration mechanism”

Prior to the incorporation of MicroProfile Config, nearly all of RESTEasy's parameters were retrieved from servlet init-params and context-params. Which ones are available depends on how a web application invokes RESTEasy.

If RESTEasy is invoked as a servlet, as in

<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">

   <context-param>
      <param-name>system</param-name>
      <param-value>system-context</param-value>
   </context-param>
   
   <servlet>
      <servlet-name>Resteasy</servlet-name>
      <servlet-class>org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher</servlet-class>

      <init-param>
         <param-name>system</param-name>
         <param-value>system-init</param-value>
      </init-param>
      
   </servlet>

   <servlet-mapping>
      <servlet-name>Resteasy</servlet-name>
      <url-pattern>/*</url-pattern>
   </servlet-mapping>
</web-app>

then the servlet specific init-params and the general context-params are available, with the former taking precedence over the latter. For example, the property "system" would have the value "system-init".

If RESTEasy is invoked by way of a filter (see Section 3.8, “RESTEasy as a Servlet Filter”), as in

<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">

   <context-param>
      <param-name>system</param-name>
      <param-value>system-context</param-value>
   </context-param>

   <filter>
      <filter-name>Resteasy</filter-name>
      <filter-class>org.jboss.resteasy.plugins.server.servlet.FilterDispatcher</filter-class>

      <init-param>
         <param-name>system</param-name>
         <param-value>system-filter</param-value>
      </init-param>

    </filter>

    <filter-mapping>
        <filter-name>Resteasy</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

</web-app>
   

then the filter specific init-params and the general context-params are available, with the former taking precedence over the latter. For example, the property "system" would have the value "system-filter".

Finally, if RESTEasy is invoked by way of a ServletContextListener (see Section 3.7, “RESTEasy as a ServletContextListener”), as in

<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">

   <listener>
      <listener-class>
         org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap
      </listener-class>
   </listener>

   <context-param>
      <param-name>system</param-name>
      <param-value>system-context</param-value>
   </context-param>
</web-app>

where ResteasyBootstrap is a ServletContextListener, then the context-params are available.

RESTEasy can receive the following configuration options from any ConfigSources that are available at runtime:

Table 3.2. 

Option Name Default Value Description
resteasy.servlet.mapping.prefix no default If the url-pattern for the RESTEasy servlet-mapping is not /*
resteasy.providers no default A comma delimited list of fully qualified @Provider class names you want to register
resteasy.use.builtin.providers true Whether or not to register default, built-in @Provider classes
resteasy.resources no default A comma delimited list of fully qualified JAX-RS resource class names you want to register
resteasy.jndi.resources no default A comma delimited list of JNDI names which reference objects you want to register as JAX-RS resources
javax.ws.rs.Application no default Fully qualified name of Application class to bootstrap in a spec portable way
resteasy.media.type.mappings no default Replaces the need for an Accept header by mapping file name extensions (like .xml or .txt) to a media type. Used when the client is unable to use an Accept header to choose a representation (i.e. a browser). See Chapter 20, JAX-RS Content Negotiation for more details.
resteasy.language.mappings no default Replaces the need for an Accept-Language header by mapping file name extensions (like .en or .fr) to a language. Used when the client is unable to use an Accept-Language header to choose a language (i.e. a browser). See Chapter 20, JAX-RS Content Negotiation for more details.
resteasy.media.type.param.mapping no default Names a query parameter that can be set to an acceptable media type, enabling content negotiation without an Accept header. See Chapter 20, JAX-RS Content Negotiation for more details.
resteasy.role.based.security false Enables role based security. See Chapter 43, Securing JAX-RS and RESTEasy for more details.
resteasy.document.expand.entity.references false Expand external entities in org.w3c.dom.Document documents and JAXB object representations
resteasy.document.secure.processing.feature true Impose security constraints in processing org.w3c.dom.Document documents and JAXB object representations
resteasy.document.secure.disableDTDs true Prohibit DTDs in org.w3c.dom.Document documents and JAXB object representations
resteasy.wider.request.matching false Turns off the JAX-RS spec defined class-level expression filtering and instead tries to match version every method's full path.
resteasy.use.container.form.params false Obtain form parameters by using HttpServletRequest.getParameterMap(). Use this switch if you are calling this method within a servlet filter or eating the input stream within the filter.
resteasy.rfc7232preconditions false Enables RFC7232 compliant HTTP preconditions handling.
resteasy.gzip.max.input 10000000 Imposes maximum size on decompressed gzipped .
resteasy.secure.random.max.use 100 The number of times a SecureRandom can be used before reseeding.
resteasy.buffer.exception.entity true Upon receiving an exception, the client side buffers any response entity before closing the connection.
resteasy.add.charset true If a resource method returns a text/* or application/xml* media type without an explicit charset, RESTEasy will add "charset=UTF-8" to the returned Content-Type header. Note that the charset defaults to UTF-8 in this case, independent of the setting of this parameter.
resteasy.disable.html.sanitizer false Normally, a response with media type "text/html" and a status of 400 will be processed so that the characters "/", "<", ">", "&", """ (double quote), and "'" (single quote) are escaped to prevent an XSS attack. If this parameter is set to "true", escaping will not occur.
resteasy.patchfilter.disabled false Turns off the default patch filter to handle JSON patch and JSON Merge Patch request. A customerized patch method filter can be provided to serve the JSON patch and JSON merge patch request instead.
resteasy.patchfilter.legacy true Set this value to false, the jsonp provider will be activated to provide PatchFilter for Json patch or Json Merge patch functionalities. By default(true value), the Jackson provider will be used.
resteasy.original.webapplicationexception.behavior false When set to "true", this parameter will restore the original behavior in which a Client running in a resource method will throw a JAX-RS WebApplicationException instead of a Resteasy version with a sanitized Response. For more information, see section Resteasy WebApplicationExceptions


Note. The resteasy.servlet.mapping.prefix <context param> variable must be set if your servlet-mapping for the RESTEasy servlet has a url-pattern other than /*. For example, if the url-pattern is

<servlet-mapping>
<servlet-name>Resteasy</servlet-name>
<url-pattern>/restful-services/*</url-pattern>
</servlet-mapping>

Then the value of resteasy.servlet.mapping.prefix must be:

<context-param>
<param-name>resteasy.servlet.mapping.prefix</param-name>
<param-value>/restful-services</param-value>
</context-param>

Resteasy internally uses a cache to find the resource invoker for the request url. This cache size and enablement can be controlled with these system properties.


The javax.ws.rs.core.Application class is a standard JAX-RS class that you may implement to provide information on your deployment. It is simply a class the lists all JAX-RS root resources and providers.

/**
* Defines the components of a JAX-RS application and supplies additional
* metadata. A JAX-RS application or implementation supplies a concrete
* subclass of this abstract class.
*/
public abstract class Application
{
    private static final Set<Object> emptySet = Collections.emptySet();

    /**
    * Get a set of root resource and provider classes. The default lifecycle
    * for resource class instances is per-request. The default lifecycle for
    * providers is singleton.
    * <p/>
    * <p>Implementations should warn about and ignore classes that do not
    * conform to the requirements of root resource or provider classes.
    * Implementations should warn about and ignore classes for which
    * {@link #getSingletons()} returns an instance. Implementations MUST
    * NOT modify the returned set.</p>
    *
    * @return a set of root resource and provider classes. Returning null
    * is equivalent to returning an empty set.
    */
    public abstract Set<Class<?>> getClasses();

    /**
    * Get a set of root resource and provider instances. Fields and properties
    * of returned instances are injected with their declared dependencies
    * (see {@link Context}) by the runtime prior to use.
    * <p/>
    * <p>Implementations should warn about and ignore classes that do not
    * conform to the requirements of root resource or provider classes.
    * Implementations should flag an error if the returned set includes
    * more than one instance of the same class. Implementations MUST
    * NOT modify the returned set.</p>
    * <p/>
    * <p>The default implementation returns an empty set.</p>
    *
    * @return a set of root resource and provider instances. Returning null
    * is equivalent to returning an empty set.
    */
    public Set<Object> getSingletons()
    {
        return emptySet;
    }

}            

Note. If your web.xml file does not have a <servlet-mapping> element, you must use an Application class annotated with @ApplicationPath.

This section is pretty much deprecated if you are using a Servlet 3.0 container or higher. Skip it if you are and read the configuration section above on installing in Servlet 3.0. The initialization of RESTEasy can be performed within a ServletContextListener instead of within the Servlet. You may need this if you are writing custom Listeners that need to interact with RESTEasy at boot time. An example of this is the RESTEasy Spring integration that requires a Spring ServletContextListener. The org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap class is a ServletContextListener that configures an instance of an ResteasyProviderFactory and Registry. You can obtain instances of a ResteasyProviderFactory and Registry from the ServletContext attributes org.jboss.resteasy.spi.ResteasyProviderFactory and org.jboss.resteasy.spi.Registry. From these instances you can programmatically interact with RESTEasy registration interfaces.

<web-app>
   <listener>
      <listener-class>
         org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap
      </listener-class>
   </listener>

  <!-- ** INSERT YOUR LISTENERS HERE!!!! -->

   <servlet>
      <servlet-name>Resteasy</servlet-name>
      <servlet-class>
         org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher
      </servlet-class>
   </servlet>

   <servlet-mapping>
      <servlet-name>Resteasy</servlet-name>
      <url-pattern>/Resteasy/*</url-pattern>
   </servlet-mapping>

</web-app>

This section is pretty much deprecated if you are using a Servlet 3.0 container or higher. Skip it if you are and read the configuration section above on installing in Servlet 3.0. The downside of running RESTEasy as a Servlet is that you cannot have static resources like .html and .jpeg files in the same path as your JAX-RS services. RESTEasy allows you to run as a Filter instead. If a JAX-RS resource is not found under the URL requested, RESTEasy will delegate back to the base servlet container to resolve URLs.

<web-app>
    <filter>
        <filter-name>Resteasy</filter-name>
        <filter-class>
            org.jboss.resteasy.plugins.server.servlet.FilterDispatcher
        </filter-class>
        <init-param>
            <param-name>javax.ws.rs.Application</param-name>
            <param-value>com.restfully.shop.services.ShoppingApplication</param-value>
        </init-param>
    </filter>

    <filter-mapping>
        <filter-name>Resteasy</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

</web-app>

JAX-RS 2.0 conforming implementations such as RESTEasy support a client side framework which simplifies communicating with restful applications. In RESTEasy, the minimal set of modules needed for the client framework consists of resteasy-core and resteasy-client. You can access them by way of maven:

<dependency>
    <groupId>org.jboss.resteasy</groupId>
    <artifactId>resteasy-core</artifactId>
    <version>4.7.3.Final</version>
</dependency>
<dependency>
    <groupId>org.jboss.resteasy</groupId>
    <artifactId>resteasy-client</artifactId>
    <version>4.7.3.Final</version>
</dependency>

Other modules, such as resteasy-jaxb-provider, may be brought in as needed.