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
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.
