[jax-rs-spec users] [jsr339-experts] Re: Filters, Interceptors and Priorities

From: Markus KARG <>
Date: Thu, 25 Oct 2012 20:24:51 +0200


thank you for your examples.

If fact there is still some open question:

> One example is GZIP encoding:
> GZIP encoding needs to wrap around the MBW
> try
> {
> setOutputStream(GZIPOutputStream);
> proceed();
> }
> finally
> {
> gzipOutputStream.finish();
> }

This can be done easily with a filter instead, which can call finish() on
itself as soon as close() is invoked. So I do not need an entity interceptor
for this:

filter(req,resp) {

> Another is DKIM signature header:
> setOutputStream(buffer);
> proceed();
> String signature = getSignature(buffer); ctx.setHeader
> outptuStream.write(buffer);

Now I see! So the ultimate use case for entity interceptors (in comparison
to filters) is when one must set a header which is dependent of the
representation. Indeed, this is impossible to do using the current filter
APIs! On the other hand, I think this example looks more like an excuse for
the fact that filters are non-wrapping, which I do not like, BTW (but I
don't want to warm up the discussion). ;-)

> Response res = target.get(); // response filters run here
> Customer cust = res.readEntity(); // ReaderInterceptors run here.

...which more is a technical explanation of filters() vs. entity
interceptors, but not really a use case in the sense of "Why should user
want to do that?". ;-)

> Another example is a client side cache that wants to cache based on
> Java object type. The filter could cache, but it doesn't know the Java
> object type the user wants yet.

Well, a use case should start with the *user's* intention, not with the
*implementation's* intention. So the use case is client side caching, which
can be done using a filter. Whether the filter is caching the representation
or the java instance does not make a big difference. The difference only
comes up when looking at performance, as caching java certainly preserves
the need for again-and-again parsing XML / JSON. And exactly this case is
why Jan and me asked if we can manually invoke a MBR manually and get the
interceptor running: If THAT is the ultimate use case for introducing
interceptors, THEN interceptors must be invoked at manual MBR calls, too.
Otherwise it would be rather strange to have a cache that works only in SOME

Thanks a lot for this really interesting insight into the use cases for an
entity interceptor! :-)