On May 21, 2013, at 5:27 PM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
> Hi All,
>
>
> On 21/05/13 16:01, Bill Burke wrote:
>>
>>
>> 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.
>>
> Well, unfortunately only under certain condition
>
> See
> https://java.net/jira/browse/JAX_RS_SPEC-405
>
> The example in JAX_RS_SPEC-405 indeed did work in 1.1 but no longer in 2.0. I believe Santiago is looking into resolving it.
I have challenged the issue above - see my comment. I do not think the example in that issue worked either.
Marek
>
> Now, in https://java.net/jira/browse/JAX_RS_SPEC-406, nearly identical case does not work positively - but it is 1.1 spec compliant. However, given that both 405 & 406 JIRAs deal with nearly identical cases, and effectively are resolving around the fact that the root resource has no matching resource methods, IMHO it makes sense to get the examples in 405 & 406 woek in a positive case
>
> Cheers, Sergey
>
>>
>>
>
>