Cross-Domain on Jersey RESTful Web Services

Jersey is based on JAX-RS Java community standard, and quite convenient for implementing a RESTful Web Services to serve various flavors of calls in backend. In general, we may use the JSONP workaround with a Javascript callback function to serve the cross-domain request. In Jersey, it provides a better way to achieve it by utilising theContainerRequestFilter interface. Most of all, we can easily adapt or remove this feature in the Web configuration file.

Here’s an example to resolve Access-Control-Origin not allowed error and you can set those parameters want you want:

 

 

 

src/main/java/com/example/filter/CORSFilter.java

1234567891011121314151617181920212223

package com.example.filter;import com.sun.jersey.spi.container.ContainerRequest;import com.sun.jersey.spi.container.ContainerResponse;import com.sun.jersey.spi.container.ContainerResponseFilter;public class CORSFilter implements ContainerResponseFilter {  @Override  public ContainerResponse filter(ContainerRequest request,          ContainerResponse response) {      response.getHttpHeaders().add("Access-Control-Allow-Origin", "*");      response.getHttpHeaders().add("Access-Control-Allow-Headers",              "origin, content-type, accept, authorization");      response.getHttpHeaders().add("Access-Control-Allow-Credentials",              "true");      response.getHttpHeaders().add("Access-Control-Allow-Methods",              "GET, POST, PUT, DELETE, OPTIONS, HEAD");      return response;  }}

The next step is to define your web.xml like so for filtering the response:

src/main/webapp/WEB-INF/web.xml

1234567891011

<servlet>    <servlet-name>Jersey Web Application</servlet-name>    <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>    ...    <init-param>        <param-name>com.sun.jersey.spi.container.ContainerResponseFilters</param-name>        <param-value>com.example.filter.CORSFilter</param-value>    </init-param>    ...    <load-on-startup>1</load-on-startup></servlet>

However, the ajax cross-domain request may accompany with another OPTIONS request, we can observe it in the Tomcat localhost_access log as following:

10.4.128.61 - - [06/Aug/2013:00:00:21 +0800] "OPTIONS /example/rest/logs HTTP/1.0" 200 52010.4.128.61 - - [06/Aug/2013:00:00:22 +0800] "POST /example/rest/logs HTTP/1.0" 200 34

“preflighted” requests first send an HTTP OPTIONS request header to the resource on the other domain, in order to determine whether the actual request is safe to send.

MOZILLA DEVELOPER NETWORK HTTP Access Control (CORS)

Also the catalina.out throws the message as:

Aug 07, 2013 7:22:55 AM com.sun.jersey.server.wadl.generators.AbstractWadlGeneratorGrammarGenerator attachTypesINFO: Couldn't find grammar element for class java.io.InputStreamAug 07, 2013 7:22:55 AM com.sun.jersey.server.wadl.generators.AbstractWadlGeneratorGrammarGenerator attachTypesINFO: Couldn't find grammar element for class javax.ws.rs.core.Response

I add the corresponding OPTIONS handler for all the @Path resource to solve the errors, however, I have no idea whether there is a better way to do this?

12345678910

@OPTIONSpublic Response myResource() {    return Response.ok().build();}@POSTpublic Response myResource() {    // do something    return Response.ok().build();}