On 13/12/12 20:26, Bill Burke wrote:
> Err... no, the idea was that the generic parameter type would take
> precedence if it was a match.
>
> If you wanted to read an InputStream
>
> @Produces("*/*")
> public BuiltinReader implements MEssageBodyReader<InputStream>
>
> would take precedence over
>
> @Produces("*/*")
> public CustomReader implements MessageBodyReader
>
Yes the above breaks it - please read the case I described carefully
Sergey
> But,
>
> CustomReader would take precedence over:
>
> @Produces("*/*")
> public Builtin2Reader implements MessageBodyReader
>
>
>
> On 12/13/2012 5:32 AM, Sergey Beryozkin wrote:
>> Recall we had a discussion with most experts agreeing that the runtime
>> should let the default providers have a chance to handle types like
>> InputStream first, as opposed to the typical case of having the custom
>> providers being tried first.
>>
>> The particular case was that suppose Jackson JSON provider was
>> registered which was simply returning 'true' in its isReadable or
>> isWriteable and the application code had InputStream in or out
>> parameter, and with the default selection Jackson would be chosen but
>> would fail working with InputStream...
>>
>> So the decision was to bypass the custom providers and let the
>> base/default providers always have a first go with InputStream or
>> primitive types...
>>
>> We've had in interesting query recently which I thought was relevant.
>>
>> CXF ships multipart provider which can work with all the types as long
>> as type-specific providers are available. For example, if the code
>> expects 'A' and the provider for A is there then the multipart provider
>> will handle the conversion of a given part to A, example:
>>
>
> What is the signature of the multipart provider?
>
>> @POST
>> @Consumes("multipart/mixed")
>> public void upload(@Multipart("root") A a) {}
>>
>> So, the provider will find a part identified as "root" and convert it
>> to A.
>>
>>
>> Next a user may want to write
>>
>> @POST
>> @Consumes("multipart/mixed")
>> public void upload(@Multipart("root") InputStream is) {}
>>
>
> You could write a multipart provider that implemented
> MessageBodyReader<InputStream>
>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com