[jax-rs-spec users] Re: [jsr339-experts] Re: HEADS-UP, IMPORTANT: Problems with JAX-RS interceptors

From: Martin Matula <>
Date: Mon, 30 Apr 2012 19:48:30 +0200

OK, so basically no changes from the status quo then. Just clarifying a few things in the spec/javadoc.
And discussing the addition of annotations on the client side which I guess can be done after EDR3.

On Apr 30, 2012, at 5:27 PM, Bill Burke wrote:

> On 4/30/12 11:05 AM, Martin Matula wrote:
>> Hi Bill,
>> On 4/30/12 4:30 PM, Bill Burke wrote:
>>>> 2) readEntity() should make an implicit call to bufferEntity() before it
>>>> does anything. This is just for filters! Not for reading in the resource
>>>> method or the client.
>>> Just a thought..Maybe it shouldn't be implicit? Maybe the filter is
>>> reading the entity, then replacing it with writeEntity(), so a buffer
>>> is overkill? Or maybe its just better to protect the filter developer
>>> from himself? I don't know...
>> OK, not implicitly buffering may provide more flexibility. On the other
>> hand one poorly written filter can break everybody else. Not sure what's
>> better. I don't have a strong opinion on this one.
>>>> 3) maybe - remove get/setEntityStream() from filters (could not find a
>>>> use-case that could not be covered by interceptors or a combination of
>>>> an interceptor and a filter that triggers the interception by calling
>>>> bufferEntity()). Or maybe we want to keep it to be safe. Which leaves us
>>>> with just the two things above.
>>>> Here is the rationale:
>>>> - on the receiving end, you want "decoding" interceptors to work based
>>>> on the headers, not based on the annotation - i.e. if the entity in the
>>>> incoming message is zipped, it is not the resource method that tells me
>>>> it is, it is the sender who should tell me - by the way of the headers.
>>>> So, typically no annotations processing should be needed to make the
>>>> stream usable for other consumers. At least I think I would never add a
>>>> feature that would not have this kind of characteristics.
>>> hashes or signatures?
>> Shouldn't the hashes/signatures be verified based on headers then? I.e.
>> if the sender sends a hash/signature, don't you always want to verify?
> Verification is expensive. Because you have to:
> a) recreate the hash
> b) encrypt the hash
> c) compare
> So, I would say, no, you don't always want to verify.
>> And only use the annotation for enforcement? That way your verification
>> interceptor can be global and the enforcement would be name-bound. And
>> things would work. Or do you need to read something from the annotations
>> which is essential for the signature/hash computation?
> Annotation could have the hashing algorithm specified. But usually the information is contained in a header somewhere.
>> Otherwise I don't know how to implement it cleanly - I guess you would
>> have to buffer headers (if you want to buffer the original stream) as
>> well, since after my gzip interceptor removes the encoding header and
>> somebody later reads the original stream from the buffer, my gzip
>> interceptor will no longer know it has to decode - unless it gets the
>> buffered original headers as well, no? The "mark" in the property bag
>> would not be enough in this case, as the interceptor does not know when
>> it works with the original stream as opposed to a new stream created as
>> a result of writeEntity(). Seems to make things too complicated, no?
> Why would a gzip interceptor remove the encoding header?
>>> * If you call writeEntity() what should happen to headers? For
>>> example, if the original wire bytes are gzip encoded and you call
>>> writeEntity() what happens to the Content-Encoding header? In this
>>> case, maybe we writeEntity() should have an additional headers parameter?
>>> public <T> void writeEntity(
>>> final MultivalueMap<String, Object> newHeaders,
>>> final GenericType<T> genericType,
>>> final Annotation annotations[],
>>> final MediaType mediaType,
>>> final T entity);
>> What would you pass to the header parameter?
>> writeEntity triggers interceptors, based on the current headers, the
>> gzip interceptor would either kick in or not, no?
> Oh yeah, I guess it would. Good point.
>> One more thing - should annotations[] be added to the client API
>> somewhere (e.g. to the methods that work with entity or to the Entity
>> class) to make name-bound interceptors reusable on the client side?
> Yes. And it would also work well with our proxy framework :)
> --
> Bill Burke
> JBoss, a division of Red Hat