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?
>
https://issues.jboss.org/browse/CTS-81
>> 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
http://bill.burkecentral.com