users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: HEADS-UP: Revise MBR selection mechanism?

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Wed, 23 May 2012 19:14:55 +0200

On May 23, 2012, at 6:43 PM, Bill Burke wrote:

> On 5/23/12 12:04 PM, Marek Potociar wrote:
>>
>> On May 23, 2012, at 4:49 PM, Sergey Beryozkin wrote:
>>
>>> On 23/05/12 15:37, Marek Potociar wrote:
>>>> Hello experts,
>>>>
>>>> please review the following issue
>>>> http://java.net/jira/browse/JAX_RS_SPEC-187 and provide your feedback.
>>>> Apparently this may be considered a BW-breaking change. If we make it,
>>>> the implementations may need to provide a BW compatibility switch if
>>>> necessary.
>>>
>>> I do not understand that issue at all. The resource method returns InputStream therefore the MBW supporting InputStream must win
>>
>> Not necessarily - see the section of the spec referenced from the issue - 4.2.2, step 4.
>>
>> The response media types takes precedence over the generic MBW type, so if the response is "application/json" InputStream and a custom Jackson JSON provider claims to support any java type (Object) for "application/json", it will win over the default InputStream provider that supports InputStream for any media type. That is however most likely not what the user wanted.
>>
>> The issue suggests to reverse this ordering.
>>
>> Also, the spec mandates that custom providers should always take precedence over the default ones, but the spec is not clear whether this should really be a primary or tertiary key. For MBW the issue suggests that the right thing would be to explicitly define it as a tertiary key.
>>
>>
>
> To have to separate implementations (Jersey and Resteasy) come to the same separate conclusion I think gives pretty good reason to change the algorithm.
>
> Beyond InputStream, really any "low-level" type would have to be treated as a special case in the current matching algorithm: InputStream, Reader, File, StreamingOutput, String, char[], and byte[]. Plus, if a user has a specific MBR/MBW for a specific type, then they probably want that MBR/MBW called no matter what. You can't get any more specific than the Java type.

All right, so I'd give Sergey some more time to review the issue but I'm glad to see that we are on the same side here.

Marek

>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com