[jira] Updated: (CXF-1653) Deviation from spec: unnecessary check for @ProduceMime of sub-resource locators

["Zagyvai Balazs (JIRA)" <ji...@apache.org>]

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

Zagyvai Balazs updated CXF-1653:
--------------------------------

    Attachment: test.zip

test case for the bug

> Deviation from spec: unnecessary check for @ProduceMime of sub-resource locators
> --------------------------------------------------------------------------------
>
>                 Key: CXF-1653
>                 URL: https://issues.apache.org/jira/browse/CXF-1653
>             Project: CXF
>          Issue Type: Bug
>          Components: REST
>    Affects Versions: 2.1
>            Reporter: Zagyvai Balazs
>            Priority: Minor
>         Attachments: test.zip
>
>
> Hi,
> I'm experimenting with restful services, and stumbled upon something that seems to be a deviation from the specification in CXF's implementation of jax-rs: when matching a request to resource methods, CXF tries to match the @ProduceMime value of sub-resource locators with the request's Accept header. See the second condition in the first line of the below code snippet from JAXRSUtils.findTargetMethod():
> if (ori.isSubResourceLocator() && matchMimeTypes(requestType, acceptType, ori)) {
> 	candidateList.put(ori, map);
> } else if (ori.getHttpMethod().equalsIgnoreCase(httpMethod)
> 		   && matchMimeTypes(requestType, acceptType, ori)) {
> The call to matchMimeTypes() in the first condition is problematic for two reasons:
>   1. (in my understanding) according to the specification, sub-resource locators never has to be filtered by media types. See spec v0.6 (https://jsr311.dev.java.net/drafts/spec20080131.pdf) section 2.5: step 2.(d) applies to sub-resource locators, and filters them only by URI template matching. Then the 4th point of step 3.(a) filters methods by matching their @ProduceMime values with the request's Accept header, but at this step we only have resource methods at hand, and no sub-resource locators at all.
>   2. This code introduces a bug by which an NPE will be thrown in the else branch of the above code snippet, when ori is a sub-resource locator, and the if condition in the first line evaluates to false due to mismatching mime-types. In this case ori.getHttpMethod() still returns null, thus ori.getHttpMethod().equalsIgnoreCase(httpMethod) throws an NPE when evaluating the second if. This happens if the first media type in the request's Accept header doesn't match with the @ProduceMime value of the sub-resource locator. (see the attached test-case showing this bug).
> Basically, it doesn't make any sense to annotate a sub-resource locator with @ProduceMime, as it doesn't produce any content, just relays the request to another resource class. The specification confirms this when stating (section 2.4 in spec v0.6): "Application classes can declare the supported request and response media types using the @ProduceMime and @ConsumeMime annotations. These annotations MAY be applied to a resource method, a resource class, or to an entity provider..." The mentioned three things don't include sub-resource locators according to the terminology in section 1.5.
> Ok, sorry for the longish description, I just wanted to propose the attached patch removing the matchMimeTypes() call from the first line above.
> Thanks,
> Balazs

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