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: Thu, 24 May 2012 17:37:00 +0100
  • List-id: <jsr339-experts.jax-rs-spec.java.net>

On 24/05/12 17:25, Marek Potociar wrote:

On May 24, 2012, at 5:14 PM, Sergey Beryozkin wrote:

On 24/05/12 15:16, Bill Burke wrote:


That is really bad practice, to have one MBR/MBW service multiple Java
types. But maybe I'm not understanding your example?


isnt it what JAXB/JSON/etc providers are actually doing all the time ?


Maybe this sheds more light?

More specific types are used as the first sort key. So, if your Java
type matches exactly to the generic type parameter of the MBR/MBW, it
will be chosen over every other one.


@Consumes("application/json")
public class JsonReader implements MessageBodyReader<Object>  {} //builtin

@Consumes("*/*")
public class InputStreamReader implemetns MessageBodyReader<InputStream>
{} // builtin


@Consumes("application/json")
public class JsonInputStreamReader implements
MessageBodyReader<InputStream>  {} // application provided provider

this is exactly what I'm suggesting above.

Consider this method:

@POST
public void post(InputStream is);


Content-Type: application/json, JsonInputStream gets picked
Content-Type: text/plain, InputStreamReader gets picked

Make more sense?

Yes it does. What exactly in the current algorithm prevents it is from 
happening now ? JsonInputStreamReader simply wins (InputStream is more 
specifc than Object)

Consider a modified situation when there is no custom JsonInputStreamReader:

In such case the JsonReader would get picked for POST {Content-type: 
application/json}. That's wrong IMO, as the InputStreamReader would be the 
one that is most certainly wanted/expected by the user as it provides 
directly the expected type (and declares to support any media type).

That effectively makes isReadable, isWritable useless. Some 'well-behaved' providers may have written in its isReadable:

if (InputStream.class == class || isPrimitive(class)) {
    return false;
}

It's a dead code with the proposed change.

You are not saying that it is wrong that JsonReader says true for all the types - which is actually a provider bug.

My only assumption here is that, as we constantly see in real life 
configurations, the JsonReader is an implementation of a JSON ->  Java Type 
binding provider (Jackson, JAXB, ...).

When it comes to marshalling/unmarshalling to/from a Java type, the Java type 
should be the most important parameter. Media type is also important, but 
should take the second position in this consideration. And then, for 
overriding purposes the custom provider should take the tertiary precedence 
over a default one. This setup makes much more sense and helps to resolve 
some configuration issues that are currently not resolvable at all.

That is not exactly the case IMHO.
It is easily resolvable by providing specialized providers and/or making a bit more work in isReadable/isWritable of the providers that catch all the types.

Cheers, Sergey


Marek


Sergey







--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.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?

Marek Potociar 05/23/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: 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