无法使用Jersey客户端过滤器覆盖响应标头

Question

I am trying to use the Jersey client API to consume a third-party REST service. I plan to use the automatic POJO deserialisation to go from JSON responses to Java objects.

Unfortunately, the third party service returns the responses using the content type "text/javascript" . My Jersey client fails to understand that this should be considered as a JSON object and fails to deserialise the object.

I wrote a simple Jersey server application to verify that by changing the content type from "text/javascript" to "application/json" that the deserialisation works.

Armed with this information, I set about to use a Jersey client filter to modify the response headers. The code comes from a comment by the author of this question . In fact, the question appears to be exactly the same as mine - however the answerer mis-answered the question and shows how to modify the request headers (rather than the response headers). The original author was able to use the answer to create his solution, but, it seems his stated solution fails to work.

The filter code is:

client.addFilter(new ClientFilter() {
  @Override public ClientResponse handle(ClientRequest cr) 
      throws ClientHandlerException {
    ClientResponse response = getNext().handle(cr); 
    response.getHeaders().putSingle(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON); 
    return response;
  }
});

When executed however, an UnsupportedOperationException is raised:

Exception in thread "main" java.lang.UnsupportedOperationException
at java.util.Collections$UnmodifiableCollection.clear(Collections.java:1035)
at com.sun.jersey.core.util.StringKeyIgnoreCaseMultivaluedMap.putSingle(StringKeyIgnoreCaseMultivaluedMap.java:78)
at com.sun.jersey.core.util.StringKeyIgnoreCaseMultivaluedMap.putSingle(StringKeyIgnoreCaseMultivaluedMap.java:56)
at App$1.handle(App.java:49)
at com.sun.jersey.api.client.Client.handle(Client.java:648)
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:680)
at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
at com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:507)
at App.main(App.java:63)

The returned headers appear to be wrapped in an unmodifiable collection.

I then attempted to copy all of the headers to a new collection, but there is no way that I can see to set a map of headers back into the response.

Finally, I thought perhaps I can create a new ClientResponse containing my amended headers. However, the constructor for ClientResponse has this signature:

public ClientResponse(int status, 
                      InBoundHeaders headers, 
                      InputStream entity, 
                      MessageBodyWorkers workers)  

It is trivial to copy the status , headers and entity variables from the original. However, I can see no way of getting a reference to the workers field.

How can I use a Jersey client filter to modify the response header from "text/javascript" to "application/json" so that my POJO deserialisation will work?

Answer 1

In Jersey 2, register an implementation of a ClientResponseFilter with the ClientConfig in order to manipulate the HTTP headers of incoming responses.

For example, this seems to work well with Jersey 2.3.1 for manipulating HTTP header:

import javax.ws.rs.client.Client;
import javax.ws.rs.client.ClientBuilder;
import javax.ws.rs.client.ClientResponseContext;
import javax.ws.rs.client.ClientResponseFilter;
import javax.ws.rs.client.ClientRequestContext;

import org.glassfish.jersey.client.ClientConfig;

/* Ensure that there is an "application/xml" Content-Type header on
 * successful responses without a content type header. */
@Provider
public static class EnsureXmlContentTypeFilter implements ClientResponseFilter {
    @Override
    public void filter(ClientRequestContext requestContext,
                       ClientResponseContext responseContext) {
        if (200 == responseContext.getStatus() &&
            null == responseContext.getHeaderString(HttpHeaders.CONTENT_TYPE)) {

            responseContext.getHeaders().add(
                HttpHeaders.CONTENT_TYPE, "application/xml"
            );

        }
    }
}

private final ClientConfig config = new ClientConfig()
    // Registering this filter adds a "Content-Type: application/xml" 
    // header to each response that lacks Content-Type headers.
    .register(EnsureXmlContentTypeFilter.class)
;
private final Client client = ClientBuilder.newClient(config);

The Jersey documentation on Filters and Interceptors isn't perfect, but it does have some links to the javadocs for the relevant classes: https://jersey.java.net/documentation/latest/filters-and-interceptors.html

I am getting XML responses from a service which responds with XML content, but lacks a "Content-Type: application/xml" header. Probably a better approach would be to register MessageBodyReaders, but the above approach works while I'm playing around with that service's API.

Answer 2

I don't have an answer to your real question, but I think I see how you can get that workers instance if you want to try to create a new response in your filter.

The "workers" object that you need appears to be a singleton. If you can get hold of your com.sun.jersey.api.client.Client instance, you can retrieve the workers object. In my case, the Jersey client code is in a unit test which subclassed JerseyTest. JerseyTest defines a method "client()" which returns the Client object. I added the following test code (well not exactly but close):

  MessageBodyWorkers workers = client().getMessageBodyWorkers();

Then I set a breakpoint in the constructor of ClientResponse (this is the original ClientResponse returned by Jersey. I have not attempted to clone it because I don't need to for my test). The workers passed to the constructor was the same instance. So, even though you can not get the workers object from the response object, you should be able to get it elsewhere.

Answer 3

Guido's answer provides the insight required to create a new ClientResponse object and return it instead. For reasons that I've not yet bothered to track down, creating a new InboundHeaders , adding all the existing headers to it, and then modifying the single header in question still fails with an UnsupportedOperationException . As such, to re-write the headers, we iterate over the original headers and build the correct set iteratively:

final Client client = Client.create(clientConfig);
client.addFilter(new ClientFilter()
{
  @Override
  public ClientResponse handle(ClientRequest cr) throws ClientHandlerException
  {
    final ClientResponse response = getNext().handle(cr); 
    final InBoundHeaders headers = new InBoundHeaders();

    for (String header : response.getHeaders().keySet())
    {
      if (header.equals(HttpHeaders.CONTENT_TYPE))
      {
        headers.putSingle(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON); 
      }
      else
      {
        headers.put(header, headers.get(header));
      }
    }

    return new ClientResponse(response.getStatus(),
                              headers,
                              response.getEntityInputStream(),
                              client.getMessageBodyWorkers());
  }
}

Answer 4

In Jersey 2, you should use a ClientResponseFilter . Then you can just call responseContext.getHeaders().putSingle(...) .

Under Java 8 you can do it with a lambda:

client.register((ClientResponseFilter) (requestContext, responseContext) ->
                responseContext.getHeaders().putSingle("Content-Type", "application/json"));

Answer 5

If you want to re-use an existing filter instance , just register it on the Client instead of on the ClientConfig .

Old way (Jersey-1.9) :

     import com.sun.jersey.api.client.Client;
     import com.sun.jersey.api.client.filter.HTTPBasicAuthFilter;

     Client client = new Client();
     client.addFilter(new HTTPBasicAuthFilter(username, password));

New way (Jersey-2.3):

     import javax.ws.rs.client.Client;
     import javax.ws.rs.client.ClientBuilder;
     import org.glassfish.jersey.client.filter.HttpBasicAuthFilter;

     Client client = ClientBuilder.newClient();
     client.register(new HttpBasicAuthFilter(username, password));

That's not the best solution , but it may help you to migrate.