> On Apr 1, 2015, at 12:17 PM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>
>>>
>>> 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 ?
>>
>> I’m not sure I follow. For MBRs we don’t sort by nearest superclass, right? Step 2 in 4.2.1 will only choose one that can produce a B. What am I missing?
>
> Step 2 in 4.2.1 only identifies B from a Java method signature.
Yes.
> Step 4 should have both A and B MBRs selected as both can handle B by returning 'true' from isReadable ?
Doesn’t that depend on the implementation of isReadable in the MBR?
>
>>
>> Perhaps providing a complete example may help :)
>
> CXF has a primitive provider (Boolean, Character, Number) as MBR<Object>,
I see where your coming from now :)
> it (now) enforces a spec requirement that these primitives are only supported by default if it is text/plain by doing an internal check in its isReadable, it has no explicit Consumes.
Why no explicit @Consumes? This does not seem right to me.
> A custom MBR<Boolean> is registered without Consumes. The test expects the default primitive provider is to be selected based on the fact the spec requires that it supports text/plain.
If the built-in had @Consumes(text/plain) and the custom @Consumes(*/*) (same as not @Consumes), then the primitive would be selected if the media type is text/plain.
>
> I think the spec does not require how its requirements that only text/plain payloads can be mapped to Boolean/etc, but I'm wondering, even if we had
>
> @Consumes(text/plain)
> BooleanAndNumberAndCharacterMBR<Object>
>
> then how would it win over a custom
>
> @Consumes(*/*)
> BooleanMBR<Boolean>
Step 3 in 4.2.1 refers to Section 4.2.3 where concrete media types like text/plain are preferred (sorted) over */* (or say text/*). Thus, isReadable should be tried on the built-in first and it should be used.
It seems that Section 4.2.1 could be a bit more specific about this “sorting” than what it is now.
— Santiago