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
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>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com