On May 20, 2013, at 9:40 AM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> On 5/20/2013 9:23 AM, Santiago Pericas-Geertsen wrote:
>>
>> Yes, I thought the original example was the other way around, but I agree with this one. I think this was an unfortunate copy/paste error in the definition of M (from earlier in step 2). It should be,
>>
>> M = { subresource methods of all classes in C′ where R(T_method) = R_match (excluding sub-resource locators) }
>>
>> which should result in M = \empty and no jump to step 3.
>>
>> Make sense?
>>
>
> There's still other holes (see my previous email). Additionally , what about this case?
Aren't we going back to the discussion of more general matching algorithms? If that's the case, you should consider enabling/disabling this extension in your implementation. Otherwise, we can't guarantee any portability between implementations, which is what we are trying to do here.
-- Santiago
>
> @Path("/")
> public class Resource {
>
> @GET
> @Path("sub")
> @Produces("application/xml")
> public String get() {...}
>
> @Path("{id}")
> public Locator locator() {...}
>
> }
>
>
> public class Locator {
>
> @GET
> @Produces("application/json")
> public String get() {...}
>
> }
>
>
> Request:
>
> GET /sub
> Accept: application/json
>
> I have a regression test for this in Resteasy from a bug that a user reported of this very case. Depending on my TCK challenges, I'm not sure yet whether I'll be able to support this case going forward.
>
> Bill
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com