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.
Cheers, Sergey
> -- Santiago
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com