Bill,
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) {
...
setEntityStream(MyFilterWhichCallsFinishAtClose(getEntityStream()));
}
> 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
cases.
Thanks a lot for this really interesting insight into the use cases for an
entity interceptor! :-)
Regards
Markus