Thanks Bill and Santiago,
that helps.
Jan
On Oct 24, 2012, at 9:14 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> 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