On 10/24/2012 2:24 PM, Markus KARG wrote:
> I think a real answer can only be provided by someone that can explain why
> he *needs* an entity interceptor at all, which I still have not understood,
> as I can do everything I need with filters.
Untrue that you can do everything with filters that you can with
interceptors. We've been through this discussion before, but I'd be
happy to explain:
This is all pseudo code:
One example is GZIP encoding:
GZIP encoding needs to wrap around the MBW
try
{
setOutputStream(GZIPOutputStream);
proceed();
}
finally
{
gzipOutputStream.finish();
}
Another is DKIM signature header:
setOutputStream(buffer);
proceed();
String signature = getSignature(buffer);
ctx.setHeader
outptuStream.write(buffer);
Both of the above need to wrap around MBWs both on client and server
side. Filters on the other hand happen before and after
request/response processing and need to execute before and after request
processing because of asynchronicity. So they are not able to wrap
around MBW, MBRs. There's also the problem of Pre/post match filters on
server side, and the fact that ClientResponseFilter could never wrap
around a MBR because it is not in the same code flow as the request
specifically:
Response res = target.get(); // response filters run here
Customer cust = res.readEntity(); // ReaderInterceptors run here.
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.
More detail is here:
http://bill.burkecentral.com/2011/05/24/interceptors-in-jax-rs-2-0/
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com