In WildFly, RESTEasy and the Jakarta RESTful Web Services API are automatically loaded into your deployment's classpath if and only if you are deploying a Jakarta RESTful Web Services application (as determined by the presence of Jakarta RESTful Web Services 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 Jakarta RESTful Web Services 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 and completely integrated as per the requirements of Jakarta EE. You can use it with Jakarta Enterprise Beans and CDI and you can rely completely on WildFly to scan for and deploy your Jakarta RESTful Web Services services and providers. All you have to provide is your Jakarta RESTful Web Services service and provider classes packaged within a WAR either as POJOs, CDI beans, or Jakarta Enterprise Beans. 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>

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-core and resteasy-client modules, 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>5.0.0.Final</version>
</dependency>
<dependency>
    <groupId>org.jboss.resteasy</groupId>
    <artifactId>resteasy-client</artifactId>
    <version>5.0.0.Final</version>
</dependency>
<dependency>
    <groupId>org.jboss.resteasy</groupId>
    <artifactId>resteasy-jaxb-provider</artifactId>
    <version>5.0.0.Final</version>
</dependency>

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

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 Jakarta RESTful Web Services class that you may implement to provide information on your deployment. It is simply a class the lists all Jakarta RESTful Web Services root resources and providers.

/**
* Defines the components of a Jakarta RESTful Web Services application and supplies additional
* metadata. A Jakarta RESTful Web Services 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 Jakarta RESTful Web Services services. RESTEasy allows you to run as a Filter instead. If a Jakarta RESTful Web Services 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>

Jakarta RESTful Web Services 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>5.0.0.Final</version>
</dependency>
<dependency>
    <groupId>org.jboss.resteasy</groupId>
    <artifactId>resteasy-client</artifactId>
    <version>5.0.0.Final</version>
</dependency>

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