On 24/05/12 17:16, Bill Burke wrote:
>
>
> On 5/24/12 11:14 AM, Sergey Beryozkin wrote:
>>> @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
>>>
>>> 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 removing JsonInputStreamReader from the list of providers
> above. In the old model the JsonReader would always match for:
>
> Content-Type: application/json
>
> @POST void post(InputStream);
>
> JsonReader would also always match for String, byte[], Reader, etc...So,
> you'd have to write and deploy an XXXInputStreamReader for each and
> every provider like JSonReader (For us we have YAML too that fits the
> same pattern).
>
I was trying to reason about it in the message you replied originally.
So yes, on one hand it sounds rather akward. On the other hand it does
not realistic that it has to be done often in real applications and as
show with your example such cases are easily managed by the user
asserting the control as opposed to relying on the assumptions.
The proposed update looks OK to me for addressing a case without a
custom JSONInputStreamReader.
I'd like to understand what happens in case of the custom provider
aserting in its readFrom() that it can support both Document &
DOMSource, where for example we also have a built in MBR<Document>
Don't get me wrong please. IMHO we need to think a lot before making a
decision which can lead to a matching *custom* provider being not
preferred to a built in one.
Thanks, Sergey