Hi
On 01/04/15 20:26, Santiago Pericas-Geertsen wrote:
>
>> On Apr 1, 2015, at 12:17 PM, Sergey Beryozkin <sberyozkin_at_talend.com
>> <mailto: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?
>
It does - my point is that if isReadable returns true it has to be selected.
>>
>>>
>>> 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.
>
What is non compliant in writing a provider that prefers to do a media
type check itself as opposed to expecting the runtime do it ?
>> 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.
>
I honestly do not get it.
How come BooleanAndNumberAndCharacterMBR<Object> will get selected if
you have said earlier that if we have B extending A, MBR<A> and MBR<B>,
a B parameter, in which case B must be selected ?
> It seems that Section 4.2.1 could be a bit more specific about this
> “sorting” than what it is now.
>
Why in quotes ?
If we have
BooleanAndNumberAndCharacterMBR<Object>
BooleanMBR<Boolean>,
then BooleanMBR<Boolean> wins, yes ? Both providers support B. The only
way to get BooleanMBR<Boolean> is to ensure it is selected in front of
BooleanAndNumberAndCharacterMBR, using a generic type as a primary key.
And if it is is the case then why the type, the primary selection key,
becomes ignored once a more specific media type is introduced into
BooleanAndNumberAndCharacterMBR<Object> ?
IMHO it is a specification bug
Cheers, Sergey
> — Santiago
>