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), java.io.Reader, java.io.File,
>> 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
http://bill.burkecentral.com