But for what reason? I mean, even a best practive must have an effective
sense.
> -----Original Message-----
> From: Bill Burke [mailto:bburke_at_redhat.com]
> Sent: Montag, 22. Oktober 2012 23:03
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: [jax-rs-spec users] ReaderInterceptor
> example question
>
> 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 [mailto:bburke_at_redhat.com]
> >> Sent: Montag, 22. Oktober 2012 18:59
> >> To: jsr339-experts_at_jax-rs-spec.java.net
> >> 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
> >> http://bill.burkecentral.com
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com