On Oct 22, 2012, at 9:38 AM, Bill Burke wrote:
> I think this is more a best-practice rather than a must, what you all think?
I agree, there's no practical reason to do this. I suppose that for certain interceptor chains it should be possible to build a contrived example in which the caller interceptor does something to the stream that would make it fail if not restored ...
-- Santiago
>
> On 10/21/2012 8:06 AM, Jan Algermissen 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
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com