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?
[1]
@Path("/")
public class Resource {
@GET
@Path("sub")
public String get() {..}
@Path("{id}")
public Locator locator(@PathParam("id") int id) {...}
}
If you have a request:
OPTIONS /sub
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
http://bill.burkecentral.com