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

From: Bill Burke <>
Date: Thu, 24 May 2012 19:57:27 -0400

On 5/24/12 5:15 PM, Sergey Beryozkin wrote:
> Hi Bill
> On 24/05/12 18:44, Bill Burke wrote:
>> On 5/24/12 12:37 PM, Sergey Beryozkin wrote:
>>> That effectively makes isReadable, isWritable useless. Some
>>> 'well-behaved' providers may have written in its isReadable:
>>> if (InputStream.class == class || isPrimitive(class)) {
>>> return false;
>>> }
>> Ooops! Your isReadable() forgot the possibility of ByteBuffer, byte[],
>> char[] (arrays aren't primitive types),,,
>> and DataSource. Not to mention any other possible custom low-level types
>> somebody might want to add: i.e. Netty's or Mina's ChannelBuffer,
>> Resteasy's MarshalledEntity, etc. etc. etc.
> The chance of the resource method returning
> ConcurrentHashMap representing the json array and thus falling into the
> 'hands' of catch-all JSON provider is very very negligible and when it
> arises it would be a good idea for the developers to actually write a
> custom MBR or MBW.

You're missing the whole point. Users often use InputStream, File,
DataSource, StreamingOutput, and byte[]. They also often have the
Jackson provider installed too. So, I know from experience that this
issue exists. We actually *already* have this matching algorithm by
default because of this issue.

> The chance of the users registering the custom provider supporting
> multiple types is much higher IMHO

Yes, but its unlikely to have a custom provider that conflicts with a
built in one that is specific to one of the "low-level" Java types
mentioned above.

Bill Burke
JBoss, a division of Red Hat