Chapter 3. Installation/Configuration

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.

RESTEasy is bundled with WildFly. However you may wish to upgrade to the latest version. With Galleon this makes upgrading RESTEasy in WildFly quite easy.

The first requirement is the WildFly installation is provisioned with Galleon. The simplest way to do this for a local installation is with Galleon CLI.

$ galleon.sh install wildfly:current

To install the RESTEasy upgrade on top of that you simply need to use the tool again with the Maven GAV:

$ galleon.sh install org.jboss.resteasy:galleon-feature-pack:6.2.6.Final

If you are using Maven to provision WildFly you can simply add the feature pack to your plugin configuration.

<plugin>
    <groupId>org.jboss.galleon</groupId>
    <artifactId>galleon-maven-plugin</artifactId>
    <configuration>
        <install-dir>${jboss.home}</install-dir>
        <record-state>true</record-state>
        <log-time>true</log-time>
        <offline>false</offline>
        <feature-packs>
            <feature-pack>
                <groupId>org.wildfly</groupId>
                <artifactId>wildfly-ee-galleon-pack</artifactId>
                <version>${version.org.wildfly}</version>
            </feature-pack>
            <feature-pack>
                <groupId>org.jboss.resteasy</groupId>
                <artifactId>galleon-feature-pack</artifactId>
                <version>6.2.6.Final</version>
            </feature-pack>
        </feature-packs>
    </configuration>
    <executions>
        <execution>
            <id>server-provisioning</id>
            <phase>generate-test-resources</phase>
            <goals>
                <goal>provision</goal>
            </goals>
        </execution>
    </executions>
</plugin>
                

RESTEasy provides an implementation of the Servlet 3.0 ServletContainerInitializer integration interface for containers to use in initializing an application. The container calls this interface during the application's startup phase. The RESTEasy implementation performs automatic scanning for resources and providers, and programmatic registration of a servlet. RESTEasy's implementation is provided in maven artifact, resteasy-servlet-initializer. Add this artifact dependency to your project's pom.xml file so the JAR file will be included in your WAR file.

<dependency>
    <groupId>org.jboss.resteasy</groupId>
    <artifactId>resteasy-servlet-initializer</artifactId>
    <version>6.2.6.Final</version>
</dependency>

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

If using Servlet versions older than 3.0, you will have to manually declare the RESTEasy servlet in the WEB-INF/web.xml file of your WAR project, and provide an Application class (see Section 3.6, “jakarta.ws.rs.core.Application”) that explicitly lists resources and providers, because the resteasy-servlet-initializer artifact does not work in Servlet versions older than 3.0. 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>jakarta.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.

If using Servlet versions older than 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>

If using Servlet versions older than 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>jakarta.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>

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:

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:

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:

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.

The MicroProfile Config API is very simple. A Config may be obtained either programatically:

Config config = ConfigProvider.getConfig();
            

or, in the presence of CDI, by way of injection:

@Inject Config config;
            

Once a Config has been obtained, a property can be queried. For example,

String s = config.getValue("prop_name", String.class);
            

or

String s = config.getOptionalValue("prop_name", String.class).orElse("d'oh");
            

Now, consider a situation in which "prop_name" has been set by System.setProperty("prop_name", "system") and also in the application's web.xml in element context-param.

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

Since the system parameter ConfigSource (ordinal = 400) has precedence over ServletContextConfigSource (ordinal = 40), config.getValue("prop_name", String.class) will return "system" rather than "context".

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 in this order:

If an application is running inside Wildfly, then all of the dependencies are automatically available. Outside of Wildfly, an application will need the Eclipse MicroProfile API at compile time.

As of RESTEasy 5.0 you will first need to add the RESTEasy MicroProfile Config dependency to the project.

        <dependency>
          <groupId>org.jboss.resteasy.microprofile</groupId>
          <artifactId>microprofile-config</artifactId>
          <scope>compile</scope>
        </dependency>
            

You will also need the MicroProfile Config API and an implementation, in our case SmallRye.

        <dependency>
            <groupId>org.eclipse.microprofile.config</groupId>
            <artifactId>microprofile-config-api</artifactId>
            <scope>compile</scope>
        </dependency>
            

        <dependency>
            <groupId>io.smallrye</groupId>
            <artifactId>smallrye-config</artifactId>
            <scope>runtime</scope>
        </dependency>
            

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.3.4, “Pre-Servlet 3.0 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.3.3, “Pre-Servlet 3.0 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.

Before adopting the default behavior, with or without MicroProfile Config, as described in previous sections, RESTEasy will use service loading to look for one or more implementations of the interface org.jboss.resteasy.spi.config.ConfigurationFactory, selecting one with the highest priority as determined by the value returned by ConfigurationFactory.priority(). Smaller numbers indicate higher priority. The default ConfigurationFactory is org.jboss.resteasy.core.config.DefaultConfigurationFactory with a priority of 500.