On May 21, 2013, at 2:02 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> 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).
I have checked with TCK team - we don't have a clue what test are you referring to. Can you please work with our TCK team offline and let them know?
> IMO, it is not much of a stretch to do this algorithm.
It's a stretch that would make it incompatible with JAX-RS 1.x. And why? So that we fit some implementations into JAX-RS compliant bounds while exposing 1.x RI users to the incompatible changes. FWIW, I'm not objecting to opening a discussion about revising/simplifying the algorithm in general, I am however not comfortable with making serious BW incompatible decisions under such pressure at all.
> 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)
Sorry for being slow here, where exactly is the current algorithm broken again?
>
> * 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.
What implementation details are you talking about?! Specifications are restricted to provide portable environments for deployment of applications that run predictably and PRODUCE SAME RESULTS FOR THE SAME OUTPUTS!!!
Marek
> 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