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

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

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Thu, 02 Feb 2012 18:56:38 +0100

On 02/01/2012 10:24 PM, Sergey Beryozkin wrote:
> On 01/02/12 19:56, Marek Potociar wrote:
>>
>>
>> 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.
>>>>>
> There definitely has to be a step there that for ensure for example that if both MyMessageBodyReader<A> and
> MyMessageBodyReader<B> are selected where B extends A then it's MyMessageBodyReader<B> that gets selected
>

Don't tell me it is there - send me a pointer to the spec text. :)

FWIW, my understanding is that the precedence of entity providers is *CURRENTLY* based only on 2 aspects:

- custom providers (i.e. the ones returned by Application.getClasses/Singletons) take precedence over the default ones
- compatibility of entity media type with the media type(s) declared in @Produces/_at_Consumes on the provider

Once the providers are ordered based on the above, first provider that returns true from isReadable/isWritable is selected.

Marek

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