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

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

From: Bill Burke <bburke_at_redhat.com>
Date: Tue, 21 May 2013 08:02:20 -0400

On 5/20/2013 3:15 PM, Marek Potociar wrote:
> 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)
>

And the TCK assumes that 2a also tries to match the HTTP method.
(Santiago admitted this is an error in the spec). IMO, it is not much
of a stretch to do this algorithm.

1. Select resource and subresource methods that match the request URI
2 if there is an http method match, and produce/consume/accept match,
then you're good
3. If there is no match for URI, http method, and
produce/consume/accept, try the locators

Markus's (and my) request to support multiple resource classes with the
same matching path was not suported in 1.1. We expanded the matching
capabilities in 2.0. I suggest we do the same again for media types.
Since this 2.0 algorithm is already broken and must be fixed, just add a
bullet point to 3(a)

* If there is no match go to step 2(i) if there are any resource
locators. If step 2(i) results in no matches then the approriate
exception must be thrown as it pertains to all matches. In other words,
if any match resulted in a 405 or 415, then 405 or 415 must be returned.


> 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.
>

Restricting a specification because of perceived implementation details
is just wrong. At least in our implementation, supporting these extra
use cases does not hurt performance other than the overhead the user has
imposed. As it is, if you are marshalling anything with these requests,
the CPU cost for that will dwarf any matching overhead.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com