Java Reference
In-Depth Information
response . setStatus ( 200 );
response . getHeaders (). putSingle ( "Content-Type" , entry . getContentType ());
ByteArrayInputStream is = new
new ByteArrayInputStream ( entry . getContent ());
response . setInputStream ( is );
The CacheResponseFilter.filter() method starts off by checking if the invoked request
was an HTTP GET. If not, it just returns. If the response status was 200, “OK,” then we ask
the Cache object to cache the response for the specific request URI. The
Cache.cacheResponse() method is responsible for buffering the response and storing relev-
ant response headers and the message body. For brevity's sake, I'm not going to go into the
details of this method. If instead the response code is 304, “Not Modified,” this means that
we have performed a successful conditional GET. We update the cache entry with any ETag
or Last-Modified response headers. Also, because the response will have no message body,
we must rebuild the response based on the cache entry. We clear all the headers from Cli-
entResponseContext and set the appropriate Content-Type . Finally we override the re-
sponse's InputStream with the buffer stored in the cache entry.
Deploying Filters and Interceptors
On the server side, filters and interceptors are deployed the same way any other @Provider
is deployed. You either annotate it with @Provider and let it be scanned and automatically
registered, or you add the filter or interceptor to the Application class's classes or
singletons list.
On the client side, you register filters and interceptors the same way you would register any
other provider. There are a few components in the Client API that implement the Configur-
able interface. This interface has a register() method that allows you to pass in your filter
or interceptor class or singleton instance. ClientBuilder , Client , and WebTarget all im-
plement the Configurable interface. What's interesting here is that you can have different
filters and interceptors per WebTarget . For example, you may have different security re-
quirements for different HTTP resources. For one WebTarget instance, you might register a
Basic Auth filter. For another, you might register a token filter.
Ordering Filters and Interceptors
When you have more than one registered filter or interceptor, there may be some sensitivities
on the order in which these components are executed. For example, you usually don't want
Search WWH ::

Custom Search