On Feb 2, 2012, at 12:56 PM, Marek Potociar 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.
According to the spec: MBRs are sorted on media type (Section 4.2.1) and MBWs are sorted on media type _and_ generic type (Section 4.2.2). Note sure why the lack of symmetry here …
-- Santiago