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

From: Bill Burke <>
Date: Tue, 21 May 2013 11:01:49 -0400

On 5/21/2013 10:50 AM, Marek Potociar wrote:
>> 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.

Its not incompatible because the matching is a superset. The current
2.0 draft is *ALREADY* a superset of JAX-RS 1.1 because it allows
multiple resource class matches. It doesn't effect compatibility
because 1.1 applications would still run with the current changes in 2.0
and the additional small change I'm proposing.

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

1.1 algorithm would go onto locators if no HTTP method was matched. See
sergey's emails.

Bill Burke
JBoss, a division of Red Hat