[jax-rs-spec users] [jsr339-experts] Re: Re: Matching algorithm doesn't recurse back on Locators

From: Bill Burke <>
Date: Mon, 20 May 2013 09:23:35 -0400

On 5/20/2013 7:22 AM, Sergey Beryozkin wrote:
> 1. 2.0 text introduces a backward incompatible text change leading to
> the ***Example 1*** not working in 2.0 any longer. IMHO this has to be
> fixed for 2.1
> 2. A little variation in the method path values (***Example 2***) leads
> to a spec-compliant non-match. Proposal:
> 2.1 Do not enforce such non-matches at the TCK level as it is wrong that
> an available Locator method is ignored with the current Resource class
> having no matching methods in the first place, I accept ***Example 2***
> will correctly per the spec return 40x, but it is totally unexpected IMHO.

This is what is weird about the TCK. You have at least one test [1]
that can only pass if you follow JAX-RS 2.0 matching algorithm strictly.
  BUT...You have a ton of other tests that fail if you follow the JAX-RS
2.0 matching algorithm strictly. So, what are we supposed to do? Dive
into Jersey code to figure out their non-compliant algorithm?


public class Resource {

     public String get() {..}

     public Locator locator(@PathParam("id") int id) {...}

If you have a request:


What is the return response? The locator() will fail because "sub"
can't be turned into a integer. There's a TCK test for this.

Bill Burke
JBoss, a division of Red Hat