jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: HEADS-UP: Revise MBR selection mechanism?

From: Bill Burke <bburke_at_redhat.com>
Date: Wed, 23 May 2012 12:43:40 -0400

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.



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