And now do
@Path("/")
public class Resource {
@Path("{sub}")
@POST
public void post();
@Path("sub")
public Locator locator;
}
class Locator {
@GET get();
@OPTIONS options();
@HEAD head();
}
Does it even concern you at all that in the above case (and as we've all
now agreed to, including yourself) that
GET /sub
and
HEAD /sub
and
OPTIONS /sub
will be correctly and as expected delivered to Locator methods ?
I'm bemused by your protecting so strongly the current algorithm which
basically loses the Locator in one case and yet keeps it, in JAX-RS 1.1
compliant way, in the above case ?
Why ? To get that @HEAD to @GET mapping working ? That is the case 1 -
the only one in fact. And I would like to ask you to come up with at
least one more example proving where the current as you say 'fixed'
algorithm can not be adapted as Bill and myself suggest (i.e - not to
lose Locators if no actual resource methods meeting HTTP verb + Media
Type requirements exist). I hope you will accept that no case number 2
exists.
I propose to fix 405 JIRA issue (in addition to 404 one which we have to
fix for obvious reasons) and make a special exception for HEAD case to
preserve the BC in this specific (and not to be recommended to any user)
case, i.e, if we have a HEAD request, no specific HEAD handler but a
default GET handler - we simply say that if it is HEAD then it matches
GET - and I can live with the fact that the Locator won;t be able to
manage HEAD in such cases.
Sergey
On 21/05/13 17:48, Marek Potociar wrote:
>
> On May 21, 2013, at 6:36 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>> On 5/21/2013 12:28 PM, Sergey Beryozkin wrote:
>>> On 21/05/13 17:24, Marek Potociar wrote:
>>>> Sergey, you are right - I failed to notice that the POST method does
>>>> not have the same literal path value as the SRL method. I apologise.
>>>>
>>> No problems Marek at all, how many times I've argued my point without
>>> reading the responses properly :-). And in this case we have a fairly
>>> deep thread :-)
>>>
>>
>> I'm lost myself...What is the conclusion? Do locators match in these situations?
>
> Here's my understanding:
>
>>
>> Requests:
>> GET /sub
>
> No. The (fixed) algorithm, compliant with JAX-RS 1.1, will match the POST method and fail in step 3.
>
>> OPTIONS /sub
>
> No. The matched POST method will cause that OPTIONS is not found in step 3 and the default OPTIONS response is provided by runtime
>
>> HEAD /sub
>
> No. The matched POST method will cause that neither HEAD nor GET is not found in step 3 and the request should fail with 405
>
> Marek
>
>>
>> @Path("/")
>> public class Resource {
>>
>> @Path("sub")
>> @POST
>> public void post();
>>
>>
>> @Path("{ID}")
>> public Locator locator;
>> }
>>
>>
>> class Locator {
>>
>> @GET get();
>> @OPTIONS options();
>> @HEAD head();
>>
>> }
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com