cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zagyvai Balazs (JIRA)" <j...@apache.org>
Subject [jira] Created: (CXF-1653) Deviation from spec: unnecessary check for @ProduceMime of sub-resource locators
Date Tue, 17 Jun 2008 14:23:45 GMT
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.


Mime
View raw message