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

[jsr339-experts] Re: [jax-rs-spec users] Re: Why is Reader/WriterInterceptor generic?

From: Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
Date: Wed, 1 Feb 2012 14:41:19 -0500

On Feb 1, 2012, at 12:17 PM, Marek Potociar wrote:

> I would prefer to make it not generic. (Alas we can't do the same for MBR/MBW…)

 With a type param you can always implement ReaderInterceptor<Object> (or, if nobody is looking, ReaderInterceptor). And when you implement ReaderInterceptor<Widget> you don't need to downcast the return from proceed():

        @Override
        public Widget aroundReadFrom(ReaderInterceptorContext<Widget> context)
                throws IOException, WebApplicationException {
            Widget w = context.proceed();
            w.setX(1);
            return w;
        }

 The framework code calling the interceptors will be uglier, I think (raw types or some explicit casts to get around existentials maybe).

 Will file JIRA for this.

-- Santiago

> On 02/01/2012 04:38 PM, Santiago Pericas-Geertsen wrote:
>>
>> On Feb 1, 2012, at 10:17 AM, Bill Burke wrote:
>>
>>> Is the generic type supposed to be used for matching purposes? i.e. if you have
>>>
>>> ReaderInterceptor<Widget>
>>>
>>> that interceptor will only be applied to that type?
>>
>> No, that was never the intent. I think we've been going back and forth on the use of generics in the interceptors. What is your preference?
>>
>> -- Santiago
>>
>>> Not good, IMO, as you would need to recalcuate interceptors chains per-request (on the client) and per-response (on the server). Is there really an existing usecase on why we need this?
>>>
>>> If you want to go this route, IMO, Reader/WriterInterceptor should have a isReadable()/isWritable() method just like MessageBodyReader/Writer has. Also you should be allowed to have @Produces/_at_Consumes which would effect binding as well.
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>