Skip to main content

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

  • From: Sergey Beryozkin <sberyozkin@...>
  • To: <jsr339-experts@...>
  • Subject: [jax-rs-spec users] [jsr339-experts] Re: Re: Re: HEADS-UP: Revise MBR selection mechanism?
  • Date: Fri, 25 May 2012 10:40:17 +0100
  • List-id: <jsr339-experts.jax-rs-spec.java.net>

On 25/05/12 00:57, Bill Burke wrote:


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.

This issue exists because some providers assume that all the types are theirs, not because the algorithm for choosing the providers is faulty.

This issue also exists when the implementations are not capable of getting multiple endpoints within the same war up and using the specific per-endpoint providers.

Sometimes such custom providers affect the flow as in case of the InputStream. But I think their right to assert that they want to deal with a given type must be preserved.

If I were to write a controlling or optimized XML provider which is 'conscious' of making sure that all the XML payloads go via it, example, those to be read into POJOs and those consumed as InputStreams, then I'd be out of luck.

As I said the proposed solution is to make sure that those all-consuming providers which blindly assert they can deal with any type do not interfere. Unfortunately, it may lead to the providers who do consume all/some types and know what to do with all of those types being side-tracked in favor of the default built-in providers which do not even care what is being copied via them or what formats are consumed or produced.


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.


What it shows that the earlier argument about Mina's ChannelBuffer and friends was not quite to the point because we are really talking about the default providers for the types (InputStream, primitives) that are to be supported by the implementation and happen to by bypassed by the all-consuming custom providers.

Anyway. I recognize the issue exists. I'm not happy with the proposed solution. I see it works in the examples that you gave but concerned it will upset more sophisticated providers. But I do not have much to offer instead but only suggesting to get custom providers registered when is really needed or introducing multiple endpoints to avoid the conflicts.

Sergey


[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?

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