jsr339-experts@jax-rs-spec.java.net

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

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Thu, 24 May 2012 17:37:00 +0100

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