Sorry for jumping so late in the discussion. It took a while to read through to the top of this thread.
On May 20, 2013, at 5:45 PM, Santiago Pericas-Geertsen <santiago.pericasgeertsen_at_Oracle.com> wrote:
>
> 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.
+1. The only major change to the algorithm was made wrt. supporting Markus in his request for multiple resource classes with the same matching paths. The essence of the algorithm remains the same. For the purpose of this conversation, that means:
1. select a first resource or sub-resource method whose effective path template fully matches the request URI
2.a if a method is selected in 1. proceed to 3. (and skip 2.b)
2.b if there are no resource and sub-resource methods with a matching path, select sub-resource locator with a matching path template and invoke it, start from 1. on the returned resource
3. select method based requested HTTP method (while providing automatic support for OPTIONS and HEAD)
The compliant programming model (no sub-resource locators for URIs directly matching resource or sub-resource methods) has been enforced by the spec algorithm from the very first version of the spec and Paul Sandoz confirmed earlier that it was done like this on purpose for performance reasons. IIUC, Marc and Paul wanted to avoid expensive SRL invocations. Users simply should not mix (sub-)resource methods and sub-resource locators for matching the same URIs. The new TCK test is only ensuring that JAX-RS compliant implementations follow the algorithm and enforce this programming model.
>
>>
>> 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.
Again, +1. Let's just try to review each on a separate email thread otherwise it's really hard to keep focus. An example, followed by the step-by-step algorithm evaluation similar to the one Sergey provided earlier would be preferred input for a discussion. That way we can easily verify the algorithm is followed properly and focus on the ambiguous parts.
Marek
>
> -- Santiago
>