Hi Sergey,
I just commented on the issue. Not sure where the "high priority" comes from as it seems to me that the issue described is quite marginal and current API provides a way how to solve the issue (not a most elegant way, but it's not a problem IMO).
Marek
On Jan 17, 2013, at 11:51 PM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
> 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
>>>
>>>
>>>
>>