[jax-rs-spec users] [jsr339-experts] Re: ReaderInterceptor example question

From: Bill Burke <>
Date: Mon, 22 Oct 2012 17:03:12 -0400

Its just a best practice, IMO. You leave the inputstream the way you
left it.

On 10/22/2012 1:13 PM, Markus KARG wrote:
> Sorry my fault -- I have read "catch" while the code says "finally"!
> On the other hand, I wonder what it actually shall be good for?
>> -----Original Message-----
>> From: Bill Burke []
>> Sent: Montag, 22. Oktober 2012 18:59
>> To:
>> Subject: [jsr339-experts] Re: [jax-rs-spec users] ReaderInterceptor
>> example question
>> On 10/22/2012 12:53 PM, Markus KARG wrote:
>>> When reading the spec I also was wondering about the same question. I
>>> think the answer is simple when looking at the response from the
>>> client side: It expects some particular data format to come. This
>> data
>>> format obviously will only be provided if *all* interceptors work
>>> correctly. If one of the interceptors fails, that data format will
>>> *not* be provided. Example: If the client requests GZIP and does not
>>> accept any other transport encoding, it makes no sense to instead
>>> provided a non-GZIPped variant. Moreover, it is a violation of the
>>> http specification, as a server must not send something that the
>>> client did not request or allow (unless the client did not specify
>> any
>>> encoding at all). In the exact example below (not a writer but a
>>> reader) the same would happen but simply reversed: The client
>> obviously sent GZIPped and the ungzipping would skip in case of
>> failure. What sense does that make?
>>> The JAX-RS resource will not be able to deal with the ZIPed data, so
>>> the request cannot be processed.
>>> To sum up: The code is wrong. It produces an incorrect response. It
>>> must be removed from the specification. Instead, the exception have
>> to
>>> be propagated to the caller, i. e. the JAX-RS implementation, to be
>> handled there.
>> The code is certainly not wrong. I really don't see what you are so
>> bother about here.
>> --
>> Bill Burke
>> JBoss, a division of Red Hat

Bill Burke
JBoss, a division of Red Hat