Hi Bill,
I can see how the interceptors and filters can work nicely together in this case. Are there more use cases like this one?
Marek
On Apr 27, 2012, at 12:23 AM, Bill Burke wrote:
> Here's "Example 3" where a ClientResponseFilter and a ReaderInterceptor work beautifully together. This also shows why you might want to allow a ReaderInterceptor the ability to return a java.lang.Object.
>
> -- Example 3: Client-side Caching --
>
> Flow:
>
> 0. Application code calls:
> Response response = target.request().get();
>
> 1. ClientRequestFilter find that the request URL is cached, but the cache may have expired
> 2. ClientRequestFilter adds If-None-Match, If-Modified-Since headers and does a conditional GET
> 3. ClientResponseFilter processes the response.
> 4. ClientResponseFilter finds that cached entity is still valid.
> 5. ClientResponseFilter updates cache entry with any new Cache-Control metadata
> 6. ClientResponseFilter sets the response InputStream to the raw representation of the resource (a gzipped XML document in this case)
> 6. ClientResponseFilter adds Content-Type header and changes Response code to 200.
> 7. ClientResponseFilter adds the cache entry to the its context's property map so that the ReaderInterceptor can reference it.
> 7. Application code calls:
>
> Foo foo = response.getEntity(Foo.class);
>
> 8. Caching ReaderInterceptor pulls the cache entry from context property map
> 9. Caching ReaderInterceptor asks the cache entry if it has ever unmarshalled Foo.class. If it has, it returns it. Done. *THIS IS AN EXAMPLE OF a READER INTERCEPTOR CHANGING THE ENTITY*. In this case, it totally bypasses the MBR.
> 10. Caching ReaderInterceptor just proceeds to the next ReaderInterceptor
> 11. GZIP ReaderInterceptor sees that the cached InputStream is gzip encoded by seeing a Content-Encoding header. It wraps the InputStream.
> 12. MBR unmarshalls the GZIPPED XML Document.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com