jsr339-experts@jax-rs-spec.java.net

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

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Mon, 22 Oct 2012 14:32:38 +0200

On Oct 22, 2012, at 12:49 PM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:

>
> On Oct 22, 2012, at 12:45 PM, Marek Potociar wrote:
>
>> Hi Jan,
>>
>> 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.
>
> I had checked on SO and found this:
>
> http://stackoverflow.com/questions/65035/in-java-does-return-trump-finally
>
> There is a pointer to the java spec in one answer.

Err... what is the connection to our use case? I thought we're discussing whether one should always "reset" the old input stream in the reader interceptor or not. The technique how one does it is orthogonal, right?

Marek

>
> Jan
>
>
>>
>> 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
>>
>