Thinking more about it...
IMHO the case I described makes it obvious why having the runtime given
the preference to the default providers in cases where it is InputStream
has a breaking consequences.
In the case where a custom provider accepts all the types 'blindly' and
then gets, as a consequence, the type it can not handle, a user
providing a custom provider around say InputStream and the media type
like "application/json" will clearly work - but I recall there were some
variations mentioned that were kind of making it difficult to do, I
don't remember the details though.
IMHO, it may make sense to start introducing a limited set of runtime
properties which are expected to lead to the runtimes treating them the
portable way:
- Application.getProperties() is introduced, and the runtime acts on the
properties mentioned at the spec/api level
in this case, a property such as
"javax.ws.rs.properties.custom.providers.first.always" (a shorter name
will do better :-)) gets introduced, the default is true or false, does
not matter, say 'false' - meaning InputStream will basically always
represent the complete payload but if a user works with multiparts and
wants InputStream point to a specific payload fragment (the part), then
this property will be set to "true".
Some other properties helping to deal with ambiguous situations can be
introduced in the future as needed
Thoughts ?
Sergey
On 13/12/12 10:32, 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:
>
> @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
>
>
>