+

Search Tips   |   Advanced Search

Deploy JAX-RS 1.1 web applications

After assembling your Java API for RESTful Web Services (JAX-RS) web application, we can deploy the web application archive (WAR) package or the enterprise archive (EAR) package onto the application server.

To deploy a JAX-RS web application, we need a WAR package or EAR package configured and enabled for RESTful services.

Every web application must have a context root for the web application to deploy successfully. A context root for each Web module is defined in the application deployment descriptor during application assembly or during application deployment. The context root is combined with the defined servlet mapping from the WAR file to compose the full URL that users type to access the servlet. The context root for each deployed web application must be unique on the server. The context root can also be empty. For instance, if a Web application used a context root of sample/application/, the web application request URL begins with http://<hostname>:<port>/sample/application/.

The URL pattern of a servlet is appended to the context root of the Web application. For example, if the context root is sample/application/ and the servlet URL mapping is rest/api/*, the base URI for the JAX-RS web application is http://<hostname>:<port>/sample/application/rest/api.


Tasks

Deploy the JAX-RS web application WAR package or EAR package onto the application server. Read about installing enterprise application files to learn more about deploying web applications.

The JAX-RS web application is deployed and ready for our business use.

Deployment of a Java API for RESTful Web Services (JAX-RS) web application is successful if we can access the application by typing a Uniform Resource Locator (URL) in a browser or if we can access the application by following a link. If we cannot access the application, follow these steps to eliminate some common errors that can occur during deployment.

Use the following tips to resolve common errors during deployment of JAX-RS web applications.

An HTTP 404 Not Found error message is sent back to the client in the server response.

To resolve this problem, take the following actions:

  • Verify that the root resource classes are annotated with a @javax.ws.rs.Path annotation and that the value in the annotation is correct. Root resource classes without a @Path annotation are not registered with the JAX-RS runtime. To learn more, see the defining the URI patterns for resources in RESTful applications information.

  • Verify that the root resource class is added to the set of classes that are returned from the getClasses() method for the subclasses of the javax.ws.rs.core.Application class. Classes that are not registered in the subclasses of the javax.ws.rs.core.Application class are not recognized by the JAX-RS runtime environment. To learn more, see the defining the URI patterns for resources in RESTful applications information.

  • Verify that the web.xmlconfiguration is correct with the expected URL patterns. Seeweb.xmlfor JAX-RS servlets and filters information.

  • Verify that the URL being used used is correct and includes the context root. If we are using a servlet, the servlet URL pattern is a part of the final URL. Using a filter might be more suitable in the web application. See web.xmlfile for JAX-RS servlets and filters information.

An HTTP 405 Method Not Allowed error message is sent back to the client in the server response.

If a request URL's servlet URI matches a resource method 's path value, but the HTTP method sent does not match the method annotation, then an HTTP status code 405 Method Not Allowed is returned.

In the following code example the request URL ends with sayhello but the request contains a POST instead of a GET, so the 405 is returned.

@javax.ws.rs.Path("helloworld")
public class SampleResource {

...

@javax.ws.rs.Path("sayhello")
@javax.ws.rs.GET
public String getHello() { ...

To resolve this problem, take the following actions:

  • Verify that the HTTP method sent matches the method annotation.

An HTTP 406 Not Acceptable error message is automatically being sent back to the client in the server response.

To resolve this problem, take the following actions:

  • Verify that the Accept HTTP request header in the incoming request is correct. To learn more, see the Implementing content negotiation based on HTTP headers information.

  • Verify that the @javax.ws.rs.Produces value on the resource method or resource class is compatible with the incoming Accept HTTP request header. To learn more, see the defining media types for resources in RESTful applications.

An HTTP 415 Unsupported Media Type error message is automatically being sent back to the client in the server response.

To resolve this problem, take the following actions:

  • Verify that the Content-Type HTTP request header in the incoming request is correct and is being sent. To learn more, see the defining media types for resources in RESTful applications.

  • Verify that the @javax.ws.rs.Consumes value on the resource method or resource class is compatible with the incoming Content-Type HTTP request header.

An HTTP 204 No Content response status is automatically being sent back to the client in the server response.

To resolve this problem, take the following action:

  • Determine if a null response in your resource should result in a 204 No Content response code.

For information about known problems and their resolution, see the IBMSupport page.

IBM Support has documents that can save you time gathering information needed to resolve this problem.

  • Define the URI patterns for resources in RESTful applications
  • Configure the web.xml file for JAX-RS servlets
  • Configure the web.xml file for JAX-RS filters
  • Use content negotiation to serve multiple content types in JAX-RS applications
  • Define media types for resources in RESTful applications
  • Install enterprise application files
  • IBM Support