On May 20, 2013, at 9:23 AM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> 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?
I'm not sure I follow your logic here. But, if we have tests that fail if you follow the JAX-RS 2.0 matching algorithm (modulo any obvious issue in the spec under discussion), then those tests should be challenged.
-- Santiago
> 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