[jira] [Updated] (ARIES-2107) Incorrect resource selection algorithm causes resource to not be found

["Amichai Rothman (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ARIES-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Amichai Rothman updated ARIES-2107:
-----------------------------------
    Description: 
I have a jax-rs whiteboard application with one resource with a @Path of "/api-docs" registered via Application.getSingletons() with a method matching "/\{path : .*}", and another resources with a @Path of "/" registered as a whiteboard service whose methods have @Paths that do not match anything like "api-docs". A request for any url under "/api-docs" returns 404 instead of being handled by the first resource.

I debugged a bit and got to cxf's JAXRSUtils.selectResourceClass() method. It starts out with all resources (including these two), and narrows the candidate list down to these two resources. However, the candidates list uses a comparator that delegates to the jaxrs whiteboard ComparableResourceComparator class, which sorts them in the wrong order, ultimately causing the "/" resource to be returned instead of the "/api-docs" one.

The comparator itself seems to use service references and ranks to perform the comparison, and only if equal, it does the actual jax-rs comparison of literal lengths and param counts etc.

I checked the osgi jax-rs whiteboard spec to see what it has to say, but all I could find is section 151.4.1.1 that states that indeed whiteboard resources should have precedence over application resources, but only if there's a conflict of two methods that map to the same URI, and all other cases should follow the standard JAX-RS sorting algorithm.

So I think the bug is that this comparator applies the "conflict" logic to all comparisons and not only to the special case of resource methods with the same URI.

I may have misinterpreted the code or the spec, if so it would be a good idea to document the code to explain why it's doing what it's doing :) though intuitively it seems like if one resource matches a request and the other does not, it should return the one that matches and not return a 404.

  was:
I have a jax-rs whiteboard application with one resource with a @Path of "/api-docs" registered via Application.getSingletons() with a method matching "/\{path : .*}", and another resources with a @Path of "/" registered as a whiteboard service whose methods have @Paths that do not match anything like "api-docs". A request for any url under "/api-docs" returns 404 instead of being handled by the first resource.

I debugged a bit and got to cxf's JAXRSUtils.selectResourceClass() method. It starts out with all resources (including these two), and narrows the candidate list down to these two resources. However, the candidates list uses a comparator that delegates to the jaxrs whiteboard ComparableResourceComparator class, which sorts them in the wrong order, ultimately causing the "/" resource to be returned instead of the "/api-docs" one.

The comparator itself seems to use service references and ranks to perform the comparison, and only if equal, it does the actual jax-rs comparison of literal lengths and param counts etc.

I checked the osgi jax-rs whiteboard spec to see what it has to say, but all I could find is section 151.4.1.1 that states that indeed whiteboard resources should have precedence over application resources, but only if there's a conflict of two resources that map to the same URI, and all other cases should follow the standard JAX-RS sorting algorithm.

So I think the bug is that this comparator applies the "conflict" logic to all comparisons and not only to the special case of resources with the same URI.

I may have misinterpreted the code or the spec, if so it would be a good idea to document the code to explain why it's doing what it's doing :) though intuitively it seems like if one resource matches a request and the other does not, it should return the one that matches and not return a 404.


> Incorrect resource selection algorithm causes resource to not be found
> ----------------------------------------------------------------------
>
>                 Key: ARIES-2107
>                 URL: https://issues.apache.org/jira/browse/ARIES-2107
>             Project: Aries
>          Issue Type: Bug
>          Components: jax-rs-whiteboard
>    Affects Versions: jax-rs-whiteboard-2.0.2
>            Reporter: Amichai Rothman
>            Priority: Major
>
> I have a jax-rs whiteboard application with one resource with a @Path of "/api-docs" registered via Application.getSingletons() with a method matching "/\{path : .*}", and another resources with a @Path of "/" registered as a whiteboard service whose methods have @Paths that do not match anything like "api-docs". A request for any url under "/api-docs" returns 404 instead of being handled by the first resource.
> I debugged a bit and got to cxf's JAXRSUtils.selectResourceClass() method. It starts out with all resources (including these two), and narrows the candidate list down to these two resources. However, the candidates list uses a comparator that delegates to the jaxrs whiteboard ComparableResourceComparator class, which sorts them in the wrong order, ultimately causing the "/" resource to be returned instead of the "/api-docs" one.
> The comparator itself seems to use service references and ranks to perform the comparison, and only if equal, it does the actual jax-rs comparison of literal lengths and param counts etc.
> I checked the osgi jax-rs whiteboard spec to see what it has to say, but all I could find is section 151.4.1.1 that states that indeed whiteboard resources should have precedence over application resources, but only if there's a conflict of two methods that map to the same URI, and all other cases should follow the standard JAX-RS sorting algorithm.
> So I think the bug is that this comparator applies the "conflict" logic to all comparisons and not only to the special case of resource methods with the same URI.
> I may have misinterpreted the code or the spec, if so it would be a good idea to document the code to explain why it's doing what it's doing :) though intuitively it seems like if one resource matches a request and the other does not, it should return the one that matches and not return a 404.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)