On Feb 2, 2012, at 4:34 PM, Sergey Beryozkin wrote:
> Hi
> On 02/02/12 21:16, Santiago Pericas-Geertsen wrote:
>>
>> 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 …
>>
> I can see it too in http://jcp.org/aboutJava/communityprocess/maintenance/jsr311/311changelog.1.1.html
>
> It's simply a minor spec bug.
You mean that the search mechanism for MBRs does not use generic types?
-- Santiago