users@jax-rs-spec.java.net

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

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Wed, 01 Feb 2012 20:56:39 +0100

On 02/01/2012 07:14 PM, Bill Burke wrote:
>
>
> On 2/1/12 12:58 PM, Marek Potociar wrote:
>> Not sure I follow. What is the purpose of isReadable/isWritable then?
>>
>
> AFAIR, the matching algorithm first calls isReadable, which can return multiple matches. ANd then from those multiple
> matches pick the best one.

I don't see that step in the spec.

Marek

>
>
>> Marek
>>
>> On 02/01/2012 06:20 PM, Bill Burke wrote:
>>>
>>>
>>> On 2/1/12 12:17 PM, Marek Potociar wrote:
>>>> I would prefer to make it not generic. (Alas we can't do the same for MBR/MBW...)
>>>>
>>>
>>> well, it makes sense on MBR/MBW cuz the generic type could be used to break ties when matching.
>>>
>>>
>>>> Marek
>>>>
>>>> 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
>>>>>
>>>
>