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.