Hi Marek, that is fine, no problems, thanks for referring to this option too
Cheers, Sergey
On 18/02/15 18:55, Marek Potociar wrote:
> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>