Amichai Rothman created ARIES-2107:
--------------------------------------
Summary: 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
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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
