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

[jsr339-experts] Default providers and types like InputStream

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Thu, 13 Dec 2012 10:32:30 +0000

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:

@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) {}

(note the query we had was not to do with this example, but it made me
think of what is going to happen with the example I'm typing now)...

So, same as with 'A', the user expects that a part identified as "root"
is returned, but the only difference is that in this case the user
simply expects a part stream reference, but *not* the whole payload
stream which contains all the multipart boundaries, possibly many more
parts, etc.

Question: how the user expectations that an individual part stream
reference is returned can be met and how Multipart provider which can
react to the annotation such as @Multipart("root") in order to find the
matching part and return an expected reference can do its job given the
fact that the default providers have to be checked first ?


Thanks, Sergey