[
https://issues.apache.org/jira/browse/CXF-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12605662#action_12605662
]
Sergey Beryozkin commented on CXF-1653:
---------------------------------------
Thanks for the patch. I'll need to confirm it on the jax-rs users list to be
100% sure.
I think you're absolutely right
> 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: JAXRSUtils.patch, 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.
