jsr339-experts@jax-rs-spec.java.net

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

From: Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
Date: Mon, 20 May 2013 11:45:47 -0400

On May 20, 2013, at 10:46 AM, Bill Burke <bburke_at_redhat.com> wrote:

>
>
> On 5/20/2013 9:52 AM, Santiago Pericas-Geertsen wrote:
>>
>> On May 20, 2013, at 9:40 AM, Bill Burke <bburke_at_redhat.com> wrote:
>>
>>>
>>>
>>> On 5/20/2013 9:23 AM, Santiago Pericas-Geertsen wrote:
>>>>
>>>> Yes, I thought the original example was the other way around, but I agree with this one. I think this was an unfortunate copy/paste error in the definition of M (from earlier in step 2). It should be,
>>>>
>>>> M = { subresource methods of all classes in C′ where R(T_method) = R_match (excluding sub-resource locators) }
>>>>
>>>> which should result in M = \empty and no jump to step 3.
>>>>
>>>> Make sense?
>>>>
>>>
>>> There's still other holes (see my previous email). Additionally , what about this case?
>>
>> Aren't we going back to the discussion of more general matching algorithms? If that's the case, you should consider enabling/disabling this extension in your implementation. Otherwise, we can't guarantee any portability between implementations, which is what we are trying to do here.
>>
>
> Usually, I'd be 100% in agreement with your portability argument, but in this case, we have a buggy algorithm that doesn't support many of these edge use cases. This is what you get when you try to standardize an implementation detail. The fact we would have to have a special switch to get around a buggy spec matching algorithm is just bullshit.

 I really don't get your rant. The essence of the algorithm has been around for many many years and, naturally, before your first implementation. The essence of the algorithm has not changed and, frankly, it's the first time I hear you complain about it. We're trying to close JAX-RS 2.0 and now the algorithm is buggy and broken? Why not bring this up before?

 If you implemented a more general algorithm, that's great, but the only reason you got away with it is that the old TCK didn't test all these cases. Of course, there may be issues with the new TCK that we need to resolve, but that's a different discussion.

>
> Instead something more general should be in the matching section:
>
> 1. Both Resource methods and locators should be taken into account to match requests
> 2. More explicit expressions take precedence over less explicit ones. i.e. @Path("path1111") takes precedence over @Path("path{id}")
> 3. If there is are resource methods that matches the path, but not the HTTP method, return 405
> 4. If there are resource methods that match the path and HTTP method, but not the media type, return 415
> 5. If the request is an OPTIONS request and there is no match, do this default behavior
> 6. If the request is HEAD and there is no match, but there is a GET request, do this default behavior...
> 7. If there is an error when matching through a locator, do this...
>
>
> Ambiguous use cases should not be tested by the TCK. What is actually categorized as "ambiguous" should be resolved by TCK challenges.

 I agree that ambiguous cases should not be tested. Please collect those and they will get reviewed.

-- Santiago