Hi All
I've opened JAX_RS_SPEC-320 few weeks ago and IMHO this is really a high
priority issue
http://java.net/jira/browse/JAX_RS_SPEC-320
Thanks, Sergey
On 13/12/12 11:37, Sergey Beryozkin wrote:
> 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
>>
>>
>>
>