[jira] Resolved: (WINK-54) Improve the algorithm to determine the MediaType of the response obj when not specified

["Bryant Luk (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WINK-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bryant Luk resolved WINK-54.
----------------------------

    Resolution: Won't Fix

This is actually a performance detriment and really the developers should specify the media types precisely.

> Improve the algorithm to determine the MediaType of the response obj when not specified
> ---------------------------------------------------------------------------------------
>
>                 Key: WINK-54
>                 URL: https://issues.apache.org/jira/browse/WINK-54
>             Project: Wink
>          Issue Type: Improvement
>          Components: Server
>            Reporter: Bryant Luk
>
> The current implementation for determining the media type of the response seems to be correct according to the spec.  However, there are situations where this does not always produce the best behavior which we can maybe improve in a future release without violating the spec.
> For instance, take:
> {code}
> @GET
> public MultivaluedMap<String, String> getMap() {
>    MultivaluedMap<String, String> aMap = ...;
>    return aMap;
> }
> {code}
> Currently I believe this essentially uses application/xml as the return MediaType.  However, the only builtin provider (I think) that can properly write this response only supports "application/x-www-form-urlencoded" so this would result in a 500 (the MultivaluedMap provider is eliminated due to it not matching that media type and then no other writer returns true from isWritable).  If this improvement is considered, performance factors should also be looked at since I'd rather have performance and make the application developers work it out.
> Of course, application developers should always add a @Consumes/@Produces or Response....type() to their methods since that would slightly improve performance anyways.  However, we should document this because of unexpected behaviors otherwise.
> Not a 0.1 blocking issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.