users@jax-rs-spec.java.net

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

From: Markus KARG <markus_at_headcrashing.eu>
Date: Mon, 22 Oct 2012 18:53:00 +0200

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.

Regards
Markus

> Interesting topic. Frankly I'm not sure if the finally clause is a must
> have in general. Event though in this case it might, but still not
> sure... I'd like to hear comments from others in this group.
>
> Marek
>
> On Oct 21, 2012, at 2:06 PM, Jan Algermissen
> <jan.algermissen_at_nordsc.com> wrote:
>
> > Hi
> >
> > in the spec it says in the reader interceptor example
> >
> >
> > @Override
> > Object aroundReadFrom(ReaderInterceptorContext ctx) ... {
> >
> > InputStream old = ctx.getInputStream();
> > ctx.setInputStream(new GZIPInputStream(old));
> > try {
> >
> > return ctx.proceed();
> > } finally {
> >
> > ctx.setInputStream(old);
> > }
> >
> > }
> >
> >
> > Which means that the old input stream will *always* be restore, not
> just in the exceptional case.
> >
> > I wonder: am I just making some stupid mistake or is that a bug in
> the text or is that a pattern that has to be applied to every reader
> interceptor anyone is going to write?
> >
> >
> > Jan