On 3/19/2014 8:31 AM, Santiago Pericas-Geertsen wrote:
> Hi Sergey,
>
>> The fact the algorithm was written the way it was does not imply 'it works as designed' in this case. It is a bug.
>
> I don't understand your point here. The JAX-RS 1.0 EG agreed on a particular type of algorithm that they thought struck a nice balance between coverage and complexity (including no backtracking). You may or may not agree with the original design, but the algorithm is sound and the fact that it doesn't cover some cases does not make it "bug", just a different design.
>
The problem is that the spec is defining implementation detail rather
than an API. With the TCK enforcing this implementation detail you've
made it impossible for us implementers to add any value. The current
algorithm is both inefficient and incomplete. And because of the
TCK/spec we can't improve it. This is just...for lack of a better
word...crap and why both users and implementers hate the JCP.
> The problem is that the general case can only be handled with backtracking, something several experts were opposed to doing. Perhaps backtracking could be avoided with "lookaheads" but then the question becomes how many do you do? Regardless, this would be a fixed number, so it will always be possible to find an example that will not be covered.
>
I personally joined the EG late and missed the backtracking arguments.
But, It is much much better to resolve to an actual method than to throw
and exception.
Doing class matches first was a lame, VERY LAME, attempt to optimize the
algorithm and causes a lot of head scratching by users. Because things
you'd expect to work don't.
What is mind boggling is you can't have something as intuitive as:
@Path("{path: .*}")
public class DefaultOptions {
@OPTIONS
public Response options() {}
}
When you can't plug in something as simple as that, that should be a
huge red flag to you that the algorithm is broken. And well, ridiculous.
>> I believe this particular case was simply not reviewed, which is all right, but ignoring the obvious problem is not the right way either IMHO.
>>
>> We have a case where a matching locator is discarded despite the fact the other matching candidates have non-matching HTTP methods.
>>
>> IMHO this needs to be fixed. The fix is cheap and requires no advanced checking of the locators. The edge case Marek referred during the last discussion on this issue to do with HEAD or OPTIONS can be carefully treated too.
>> By the way, I'd like to initiate a vote regarding this issue but perhaps this can be postponed till 3.0. 3.0 would be Ok for me.
>
> As I said above, the difficulty here is where to draw the line between what it is and what it isn't covered by the algorithm. I suggest that you take the existing algorithm as it in the spec, and propose modifications to it in such a way that it remains sound (backward compatible) with the original. If that could be done, without significantly increasing complexity, I do not see why we couldn't improve on the original design.
>
I'd rather just the TCK stop testing these edge cases.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com