On May 21, 2013, at 5:01 PM, Bill Burke <bburke_at_redhat.com> 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 problem is that with default OPTIONS and HEAD there are use cases that suddenly would start working differently:
@Path("root")
class Root {
@GET
@Path("sub")
String getSub() { ... }
@Path("sub")
Sub getLocator() { return new Sub(); }
}
class Sub {
@OPTIONS
String options() { ... }
}
With JAX-RS 1.1, the above example, for an OPTIONS request to "/root/sub" requires default OPTIONS method to be invoked. Your proposal would change this to invocation chain Root.getLocator() -> Sub.options(). That is my problem with your proposal.
> 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.
But if I'm correct, the change we made does not pose the same issues as the change being proposed now. We're just enabling something that was clearly forbidden earlier. I do not think that there are any JAX-RS compliant applications out there that contain multiple root resource classes with the same @Path values.
>
>>> 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.
I see now, thanks. So to be JAX-RS 1.1 compliant we need to update the step 2.(i) to something like:
Let L be a sub-resource locator such that Rmatch = R(TL). Implementations SHOULD report an error if there is more than one sub-resource locator that satisfies this condition. Invoke the sub-resource locator method of O and set O to the value returned from that method. Set U to be the value of the final capturing group of R(TL) when matched against U, and set C′ to be the singleton set containing only the class of O.
Correct?
Marek
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com