Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Message-ID: <25923513.565131282762824124.JavaMail.jira@thor>
Date: Wed, 25 Aug 2010 15:00:24 -0400 (EDT)
From: "Sergey Beryozkin (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Subject: [jira] Commented: (CXF-2903) Unexpected HTTP response code for
 @Consumes mismatch
In-Reply-To: <3218510.509101279759911415.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CXF-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902578#action_12902578 ] 

Sergey Beryozkin commented on CXF-2903:
---------------------------------------

Well, I got a bit confused yesterday while writing that long comment above :-). I'm still mostly standing by it, except that there's indeed a bug in CXF leading to 404 being returned despite the fact that in the example webapp we have a case of

2 path matches
2 produce matches
1 method mismatch (405)
1 consume mismatch (415)

The code like this :

int status;
        
        // criteria matched the least number of times will determine the error code;
        // priority : path, method, consumes, produces;
        if (pathMatched <= methodMatched && pathMatched <= consumeMatched && pathMatched <= produceMatched) {
            status = 404;
        } else if (methodMatched <= pathMatched && methodMatched <= consumeMatched 
            && methodMatched <= produceMatched) {
            status = 405;
        } else if (consumeMatched <= pathMatched && consumeMatched <= methodMatched 
            && consumeMatched <= produceMatched) {
            status = 415;
        } else {
            status = 406;
        }

will ensure that in the case of multiple non-matches the least matched criteria will be used to determine the error code, so if we have say consumes matching only once while the method has been matched twice in the case of two resource methods, then 415 will definitely be returned, etc. 

But in this particular case we'll get 405 simply because of the order of branches above. Changing the order would make it more precise in this case but will likely be less in other cases.

What you can do is to spread methods dealing with GET, PUT, etc across multiple root resources.
And, if needed (if such resources have identical class-level @Path value), register a custom ResourceComparator as a jaxrs provider :
http://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/ext/ResourceComparator.java

which will have a map like this :

"GET" : ReadableRootResource
"PUT" : UpdatableRootResource
etc

and then in the comparator you can get the Message.HTTP_REQUEST_METHOD and select the root resource class which will be used to find the resource method.

This will ensure you always get correct 415 or 406 in case of consumes or produces non-matches


> Unexpected HTTP response code for @Consumes mismatch
> ----------------------------------------------------
>
>                 Key: CXF-2903
>                 URL: https://issues.apache.org/jira/browse/CXF-2903
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 2.2.9, 2.2.10
>            Reporter: Donal Fellows
>         Attachments: example.zip, taverna.log
>
>
> I have an interface with a method annotated as accepting XML (with {{@Consumes("application/xml")}} and {{@POST}}) and a class that implements that interface; the {{@Path}} is not matched for {{@POST}} by any other method. When I call it and pass in content with that MIME type, it all works. When I pass in content of another MIME type, I get a 404 response; this is unexpected, as I'd expect a 406 (Not Acceptable) response that tells me to pass in XML (to be clear, this _is_ an error case). Having to work around this by accepting all types and doing my own content type negotiation is unacceptable, especially since that decreases the utility of the generated WADL file significantly. Surely CXF should be doing this sort of work for me?

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