cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CXF-1653) Deviation from spec: unnecessary check for @ProduceMime of sub-resource locators
Date Tue, 17 Jun 2008 17:13:45 GMT

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


Mime
View raw message