You have learned multiple resource configurations and packaging models for JAX-RS applications in the previous chapter under the A quick look at the packaging of JAX-RS applications section. A common approach is to subclass javax.ws.rs.core.Application and configure the RESTful resources by overriding the appropriate methods.

The Jersey framework  eases the configuration of resources via a custom class, org.glassfish.jersey.server.ResourceConfig, which extends the JAX-RS core class,  javax.ws.rs.core.Application. We have used the Application class in the previous chapter for configuring a vanilla JAX-RS application. The ResourceConfig class offers many extra configuration features on top of the standard JAX-RS Application class. With the ResourceConfig class, you can define the JAX-RS resources via an array of class names; you can even specify the package names where you have defined the JAX-RS component. During deployment, Jersey will automatically discover and register all the components found in the packages that you set.

What if you want to define a JAX-RS resource during deployment? Apart from static resource class definitions, Jersey allows you to define and configure the JAX-RS components during the deployment of the application. The following is an example that illustrates this idea.

In this example, we will build a REST API resource during deployment to return the server information. We will expose this API only to selective customer deployments, managed via an application configuration parameter. The following code snippet illustrates how you can do this with the Jersey APIs. While deploying the application, the ApplicationConfig class that you see in the code snippet will read the context parameter's system.info.allow entry from web.xml. If this flag is configured to return true, then ApplicationConfig will build a REST resource method during the deployment in order to return the system information for the REST API, with GET /server/info HTTP/1.1 as the path URI:

//Other imports are omitted for brevity 
import org.glassfish.jersey.process.Inflector; 
import org.glassfish.jersey.server.ResourceConfig; 
import org.glassfish.jersey.server.model.Resource; 
import org.glassfish.jersey.server.model.ResourceMethod; 
import org.glassfish.jersey.filter.LoggingFilter; 
import org.glassfish.jersey.media.multipart.MultiPartFeature; 
 
@Provider 
 
@javax.ws.rs.ApplicationPath("webresources") 
public class ApplicationConfig extends ResourceConfig { 
  
   private String configSysInfoParam = "true";

   @Context
   public void setServletContext(ServletContext context) {
       //Read the context param
       if(context != null)
         configSysInfoParam = context.getInitParameter("system.info.allow");
       
   }
    public ApplicationConfig() { 
         
         // Package names that will be used  
         //to scan for components. 
        packages("com.packtpub.rest.ch5"); 
      
        boolean allowViewServerInfo =  
            (configSysInfoParam == null) ?  
             false : Boolean.valueOf(configSysInfoParam);       
        
       //if param 'system.info.allow=true',register REST Resources
       if (allowViewServerInfo) { 
            addResources();
        } 
    } 
    
    //Add resource to return server information during deployment
    private void addResources()
    {
         //Omitted for brevity
    }
} 

The sample response content generated by the newly added resource for the GET /server/info HTTP/1.1 REST API call may look like the following:

{"hostName":"localhost","processor":"Intel","serverName":"XXX","threads":334235235,"userSessions":123233}

Let's briefly discuss some of the core APIs used in this example. The org.glassfish.jersey.server.model.Resource.Builder instance that you will obtain by calling Resource.builder() has many useful builder methods for generating a complete REST resource dynamically. Some of the important methods in Resource.Builder that need your attention are as follows:

• Resource.Builder::path(String path): This method defines the path for the resource that you build. The client can use this URI path to invoke the resource.
• Resource.Builder::addMethod(String httpMethod): This method adds a new HTTP method model to the resource. The httpMethod parameter defines specific HTTP request types (such as GET, POST, and PUT) to which this method responds to. This call returns an instance of org.glassfish.jersey.server.model.ResourceMethod.Builder, which can later be used for building the body for the method.
• You can dynamically implement the method for handling the REST call by invoking handledBy(Class<? extends Inflector> inflectorClass) on ResourceMethod.Builder.
• ResourceConfig::registerResources(Resource... resources): This method registers newly created resource models in ResourceConfig.