On Mar 13, 2013, at 3:34 PM, Marek Potociar <marek.potociar_at_oracle.com> wrote:
>
> On Mar 13, 2013, at 3:01 PM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>
>> Hi
>>
>> I have a doubt about ContainerResponseContext#getMediaType method which returns the media type of the entity.
>>
>> Consider this example:
>>
>> Accept: application/json, application/xml;q=0.8
>>
>> @Produces("application/json; application/xml")
>>
>> The intersection should get "application/json" selected and if it is done before the response filters run, then ContainerResponseContext#getMediaType works OK.
>>
>> Now, if we have no JSON Provider registered (not a mistake), the consumer should get XML back, so the final response media type should really be selected depending on the available message body writers, example, if no JSON provider registered then it actually has to be
>
> IMO, the above is a clear user bug. If an application claims to support generating JSON, it MUST have a JSON provider registered! Think about a scenario where a client sends just "Accept:application/json"... Also in your case above - the client clearly prefers JSON and the resource method is declared to produce JSON. JAX-RS runtime should thus choose the JSON as the response type. JAX-RS runtime should not try to be too smart and rule out produce declarations that are not backed by a MBW.
Of course you can be smart and try to detect and report these issues during deployment, for example.
Marek
>
> Marek
>
>>
>> "application/xml" - the problem here is that container response filters and writer interceptors run before MBWs are checked, and thus ContainerResponseFilter implementations may see the media type which will not actually be the final response media type.
>>
>> Does the above make sense, as far as describing the possible issue ?
>> At the moment I'm thinking to actually pre-check available MBWs in case of non-null response entities before the filters run, and then re-check them again if the entity is still not null and the content type gets changed during the filter/writer interceptor processing.
>>
>> Sergey
>>
>>
>>
>>
>