You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wink.apache.org by "Bryant Luk (JIRA)" <ji...@apache.org> on 2010/09/10 00:45:32 UTC

[jira] Resolved: (WINK-286) GET methods fail to serve requests without Content-Type if the class/interface has @Consumes

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

Bryant Luk resolved WINK-286.
-----------------------------

         Assignee: Bryant Luk
    Fix Version/s: 1.1.2
       Resolution: Fixed

I went ahead and changed the default behavior for the "smarter" behavior.  If you change the wink-default.properties value, then it will revert to the old behavior.  In this case, instead of changing too many method signatures, I just faked a wildcard media type for Consumes/Produces in "smart" cases.

I didn't run CTS so I have no idea if this is a violation or not.

> GET methods fail to serve requests without Content-Type if the class/interface has @Consumes
> --------------------------------------------------------------------------------------------
>
>                 Key: WINK-286
>                 URL: https://issues.apache.org/jira/browse/WINK-286
>             Project: Wink
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 1.1
>            Reporter: Raymond Feng
>            Assignee: Bryant Luk
>             Fix For: 1.1.2
>
>
> When the JAX-RS resource (the method with @GET) is accessed from a web browser, the Content-Type is not set and it's default to application/octet-stream. Wink fails to match to the method as it inherits @Consumes (say, application/json) from the class/interface and it is not compatible with application/octet-stream. For example:
> @Produces(MediaType.APPLICATION_JSON)
> @Consumes(MediaType.APPLICATION_JSON)
> public interface Catalog {
>    @GET
>    List<Item> get();
>    @GET
>    @Path("{id}")
>    Item get(@PathParam("id") String id);
> }
> The GET method doesn't have the request entity. Why do we need to compare the media type for the request? I assume we should only check the methods that take the HTTP body. 
> I had to work around this issue for Tuscany to add */* or application/octet-stream to the GET method's consumes set. It's ugly :-(.
>     private synchronized void fixMediaTypes(DeploymentConfiguration config) {
>         if (fixed) {
>             return;
>         }
>         // FIXME: A hacky workaround for https://issues.apache.org/jira/browse/TUSCANY-3572
>         ResourceRecord record = config.getResourceRegistry().getRecord(resourceClass);
>         for (MethodMetadata methodMetadata : record.getMetadata().getResourceMethods()) {
>             String method = methodMetadata.getHttpMethod();
>             if (HttpMethod.GET.equals(method) || HttpMethod.HEAD.equals(method) || HttpMethod.DELETE.equals(method)) {
>                 methodMetadata.addConsumes(MediaType.APPLICATION_OCTET_STREAM_TYPE);
>                 methodMetadata.addConsumes(MediaType.WILDCARD_TYPE);
>             }
>             if (HttpMethod.HEAD.equals(method) || HttpMethod.DELETE.equals(method)) {
>                 methodMetadata.addProduces(MediaType.APPLICATION_OCTET_STREAM_TYPE);
>                 methodMetadata.addConsumes(MediaType.WILDCARD_TYPE);
>             }
>         }
>         for (MethodMetadata methodMetadata : record.getMetadata().getSubResourceMethods()) {
>             String method = methodMetadata.getHttpMethod();
>             if (HttpMethod.GET.equals(method) || HttpMethod.HEAD.equals(method) || HttpMethod.DELETE.equals(method)) {
>                 methodMetadata.addConsumes(MediaType.APPLICATION_OCTET_STREAM_TYPE);
>                 methodMetadata.addConsumes(MediaType.WILDCARD_TYPE);
>             }
>             if (HttpMethod.HEAD.equals(method) || HttpMethod.DELETE.equals(method)) {
>                 methodMetadata.addProduces(MediaType.APPLICATION_OCTET_STREAM_TYPE);
>                 methodMetadata.addConsumes(MediaType.WILDCARD_TYPE);
>             }
>         }
>         fixed = true;
>     }

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