Hi Santiago
Thanks for a quick reply and apologies for a delay - I headed to the
airport straight after I sent this message :-), checking the messages today,
See comments below:
On 26/03/15 13:01, Santiago Pericas-Geertsen wrote:
> Hi Sergey,
>
>> Sort the selected MessageBodyWriter providers with a primary key of generic type where providers whose generic type is the nearest superclass of the object class are sorted first and a secondary key of
>> media type (see Section 4.2.3).
>>
>> and for MBRs:
>>
>> Select the set of MessageBodyReader classes that support the media type of the request, see Section 4.2.3.
>>
>>
>> Why the MBR text does not refer to the Java parameter type as a primary key for sorting the providers, with the media type being the secondary keys.
>
> Of course MBRs do take into account the Java type, but there is no sorting as you point out.
>
> Suppose B extends A. If your resource parameter is of type B, there’s no point in using a MBR that can only produce A, you really need a B.
And if an MBR B does not exist the MBR A can still return B (example,
Object-typed JAXB or JSON readers returning Object subclasses), I'm just
adding the details, as opposed to disagreeing at this stage...
> On the other hand, if your method returns B, you may be able to use a MBW for A if one for B does not exist —it will at least serialize a part of the object.
>
> By the same token, you could argue that if C extends B, then you could use a MBR for C to produce a B. So for readers you could use subtypes instead of supertypes. I don’t know the history if this, but I suppose readers were assumed to be strict (needing to deserialize complete objects) while writers were not.
This is fine but this rule where a B MBR is obviously better than an A
MBR does not hold if A MBR has a more specific media type.
I feel there's something that needs to be improved/clarified here.
Consider two cases below (in both cases a resource parameter is B
extending A), with a POST text/plain body.
Case1.
@Consumes(*/*)
MBR<A>
and
@Consumes(*/*)
MBR<B>
Obviously B wins - as you said it does not make sense to choose the A
MBR if the B MBR exists.
Case2.
@Consumes(text/plain)
MBR<A>
and
@Consumes(*/*)
MBR<B>
Suddenly MBR A wins ? If so then MBR<A> may return A where B is expected
? And if MBR B still wins then it is a case of MBRs being sorted,
because MBR<A>, example, JAXBReader<Object>, can still support B, and as
such both readers are candidates ?
What do you think ?
Thanks, Sergey
>
> — Santiago
>