Skip to main content

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

  • From: Bill Burke <bburke@...>
  • To: jsr339-experts@...
  • Subject: [jax-rs-spec users] [jsr339-experts] Re: Re: Re: HEADS-UP: Revise MBR selection mechanism?
  • Date: Thu, 24 May 2012 19:57:27 -0400
  • List-id: <jsr339-experts.jax-rs-spec.java.net>



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


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

(continued)

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

Sergey Beryozkin 05/24/2012

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

Bill Burke 05/24/2012

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

Marek Potociar 05/24/2012

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

Sergey Beryozkin 05/24/2012

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

Bill Burke 05/24/2012

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

Sergey Beryozkin 05/24/2012

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

Marek Potociar 05/24/2012

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

Sergey Beryozkin 05/24/2012

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

Bill Burke 05/24/2012

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

Sergey Beryozkin 05/24/2012

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

Bill Burke 05/24/2012

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

Sergey Beryozkin 05/25/2012
 
 
Close
loading
Please Confirm
Close