By the way, if JIRA 405 does get fixed - I'm personally OK with waiting
till 2.1 and in meantime just get related tests excluded for now till we
agree for sure.
IMHO, fixing JIRA 405 with the special addition for HEAD to GET mapping
will preserve BC, except that the negative tests will start failing - I
don't expect any production code starting failing though
Sergey
On 21/05/13 21:09, Sergey Beryozkin wrote:
> 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