On May 22, 2013, at 3:06 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> On 5/22/2013 5:13 AM, Sergey Beryozkin wrote:
>>> I don't agree with how you guys decided how locators were matched in
>>> 1.1. JAX-RS 1.1 Step 2(h) talks about subresource methods, not
>>> locators. (Same as JAX-RS 2.0 except JAX-RS 2.0 adds more explicit
>>> language).
>> Just read carefully the described sequence in my previous email please
>>
>
> I still don't understand why this works in 1.1. Your previous email just glosses over steps 2g-i.
>
> GET /sub
>
> @Path("/")
> public class Resource {
> @POST
> @Path("{id}")
> public void post();
>
> @Path("sub")
> public Resource locator() {
> }
>
> @GET
> public void get();
> }
> }
>
> From 2(h) spec version 1.1
>
> "If R(match) was derived from T(method) then set
> M= {subresource methods of O where R(Tmethod) = Rmatch}
> Goto Step 3"
In this case however R(match) is not derived fro Tmethod but from Tlocator, because in step 2(f) spec 1.1, the R(Tlocator) will be sorted ahead of R(Tmatch) as it has more literal characters. So 2(h) is effectively skipped and 2(i) and 2(j) follow, that invoke the locator and re-start the step 2. to match the remainder of the request URI path.
To simulate the algorithm steps for this particular case:
1.a: U = "/sub", C = {Resource.class}, E = []
1.b: E = [Resource.class -> "(/.*)?"]
1.c: E = [Resource.class -> "(/.*)?"] // no change
1.d: // skipped - E is not empty
1.e: // no change
1.f: Rmatch = "(/.*)?", U = "/sub", O = resource // (resource instanceof Resource)
2.a // skipped - U is not empty
2.b C = Resource.class, E = []
2.c E = [
post() -> R(Tmethod):"([^/]+?)(/.*)",
locator() -> R(Tlocator):"sub(/.*)",
get() -> R(Tmethod):"(/.*)"
]
2.d E = [
post() -> R(Tmethod):"([^/]+?)(/.*)",
locator() -> R(Tlocator):"sub(/.*)",
]
// entry for get() was filtered out
2.e // skipped - E is not empty
2.f E = [
locator() -> R(Tlocator):"sub(/.*)",
post() -> R(Tmethod):"([^/]+?)(/.*)",
]
2.g Rmatch = R(Tlocator):"sub(/.*)"
2.h // skipped - Rmatch not derived from Tmethod
2.i U = null, invoked resource.locator(), O = resource2
2.j goto 2.a
2.a M = {get()}, goto 3.
3. ...
HTH,
Marek
>
> subresource methods != subresource locators. So, while locator() is the first match, it is excluded because M only matches to subresource methods of "O", *NOT* subresource locators of "O". I need to somebody to point why my interpretation is wrong, because otherwise I'm just going to have to guess how the algorithm works.
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com