Hi Sergey,
Sorry for not being clear – what I meant is that section 4.2.4 of the spec does not preclude you from shipping a String MBW that declares in @Produces “text/plain” as well as “*/*”. If you do that, your implementation will always resolve the ambiguous “text/*” into “text/plain” using the @Produces information from your MBW.
Marek
> On 18 Feb 2015, at 14:45, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>
> Hi Marek,
>
> Are you referring to the fact a custom ContainerResponseFilter can set a final response media type to a concrete type if the current one has a wildcard ?
> That is true. I guess it is better than defaulting. It resolves it then as far as I'm concerned.
>
> Thanks, Sergey
>
> On 18/02/15 13:36, Marek Potociar wrote:
>> I would personally prefer we do not add more defaults. It makes things confusing and every implementation is already able to deliver default providers that will deal with this situation.
>>
>> Cheers,
>> Marek
>>
>>
>>> On 17 Feb 2015, at 23:29, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>>>
>>> Hi Santiago
>>>
>>> It sounds convincing.
>>>
>>> I guess I'd only consider adding one more default,
>>> text/* -> text/plain.
>>>
>>> application/* -> application/octet-stream
>>> is already there and it works because ultimately any application/* is an octet stream.
>>>
>>> I just think that it is not 'friendly' for the following code
>>>
>>> String text = target.request("text/*").get(String.class);
>>>
>>> to fail with the 406-related exception in the case where a server has a text/* too.
>>>
>>> If we have multipart/* or image/* - it is different but text/plain can be a default.
>>>
>>> Do you reckon it may make sense to do a minor text update or prefer keep it unchanged ? Minor issue as far as I'm concerned
>>>
>>> Thanks, Sergey
>>>
>>>
>>> On 17/02/15 20:13, Santiago Pericas-Geertsen wrote:
>>>> Hi Sergey,
>>>>
>>>> I personally think that if a _static_ type is not concrete, like text/*, then the _dynamic_ type should be concrete. In other words, in this case the application code should return a Response with the actual media type in the family text/* that it wants to use, such as text/plain.
>>>>
>>>> If it does so, the algorithm in Section 3.8 stops after step (1). In addition, the static type could be a list of concrete types, which would also be an improvement. We could add more defaults, but frankly these are just guesses and nothing more.
>>>>
>>>> — Santiago
>>>>
>>>>> On Feb 16, 2015, at 4:51 PM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> I'm resuming this thread that was started at the JSR-339 list (more comments to the original email can be checked at that list).
>>>>> I've just seen another CXF issue opened specifically to do with this issue.
>>>>>
>>>>> The client does:
>>>>> GET /a
>>>>> Accept: text/*
>>>>>
>>>>> The server has
>>>>>
>>>>> @Produces(text/*)
>>>>> @GET @Path("/a")
>>>>>
>>>>> The spec requires 406 in this case and this just appears to be wrong.
>>>>> Neither a client nor a server have made a mistake: the client is stating it can take any text variations, the server is expecting the client to specify a concrete Accept - in fact some other clients may do just that.
>>>>>
>>>>> Any ideas how it can be improved ?
>>>>> Given a final text/*, what can server actually return ?
>>>>>
>>>>> CXF does application/octet-stream. The client can at least react to the possible deserialization issue locally or it may even work if String is expected for example.
>>>>>
>>>>> Should we at least provide the defaults for some well known types, IMHO this might be a reasonable compromise.
>>>>>
>>>>> For example, the spec defaults application/* to application/octet-stream. Similarly text/* can be to text/plain. Do the same for few more well known types ?
>>>>>
>>>>>
>>>>> Thanks, Sergey
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 23/04/13 14:01, Santiago Pericas-Geertsen wrote:> Hi Sergey,
>>>>>>
>>>>>> Certainly something we can look at in 2.1. I think this is a result of using wildcards in @Produces, something that I believe should be generally avoided. We can certainly look at this algorithm again and try to improve it.
>>>>>>
>>>>>> -- Santiago
>>>>>>
>>>>>> On Apr 22, 2013, at 12:49 PM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> Section 3.8 concludes with
>>>>>>>
>>>>>>> 9. If M contains ‘*/*’ or ‘application/*’, set Mselected = ‘application/octet-stream’, finish.
>>>>>>> 10. Generate a NotAcceptableException (406 status) and no entity.
>>>>>>>
>>>>>>> I'm seeing an early test failing where we have
>>>>>>>
>>>>>>> Accept: text/*
>>>>>>> Produces: text/*
>>>>>>>
>>>>>>> CXF produces: 200 + application/octet-stream, test expects 406.
>>>>>>> It is not a big problem for us to make sure that if a wildcard response types does not meet requirements from 9, them it is 406 (as per 10.), however, I wonder, should we always do 9. whenever a response type contains "*", not only if it is a wildcard or application/* ?
>>>>>>>
>>>>>>> It is kind of strange to get 406 returned when a match has been successful.
>>>>>>>
>>>>>>> I can open a minor improvement request for 2.1 if you agree
>>>>>>>
>>>>>>> Sergey
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>