On May 22, 2013, at 12:41 PM, Marek Potociar <marek.potociar_at_oracle.com> wrote:
>
> On May 22, 2013, at 12:20 PM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>
>> Hi Marek,
>> Sorry, did not finish my P.S
>>
>> I meant to say: if possible consider not enforcing the dropping of Locators at the TCK level for now till this issue gets completely sorted out in the next release, though it is up to you, I will be introducing a custom property to avoid the drop of locators in all the cases
>
> I do not want to sound stubborn, but those TCK tests are not there to bully you guys implementing the spec. Those are there to enforce that all implementations (at least in some spec-compatibility mode) behave the same way thus ensuring portability of JAX-RS apps. Those newly added tests should have been there since JAX-RS 1.0. It's our shame they were not there.
>
> I am not against you providing a configuration options that will allow your users to change your matching algorithm strategy. But in order to pass the TCK, you should be able to provide an algorithm configuration that matched the spec exactly and passes the TCK (and I would prefer you have this compatible mode enabled by default, but that's totally your call).
Ok, I need to take back what I wrote in the last paragraph above - I was just reminded about the compatibility rules:
The Product must be able to satisfy all applicable compatibility requirements, including passing all Conformance Tests, in every Product Configuration and in every combination of Product Configurations, except only as specifically exempted by these Rules.
For example, if a Product provides distinct Operating Modes to optimize performance, then that Product must satisfy all applicable compatibility requirements for a Product in each Product Configuration, and combination of Product Configurations, of those Operating Modes.
So, every implementation MUST be compatible in ALL operating modes. I.e. implementations MUST NOT provide modes that are not compatible.
Marek
>
> Marek
>
>>
>> Thanks, Sergey
>> On 22/05/13 11:16, Sergey Beryozkin wrote:
>>> Hi,
>>> On 22/05/13 10:59, Marek Potociar wrote:
>>>>
>>>> On May 21, 2013, at 10:09 PM, Sergey Beryozkin <sberyozkin_at_talend.com>
>>>> 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 understand your point and I can see that it may be in some cases
>>>> slightly confusing, but I have to put those feelings aside here. The
>>>> matching algorithm is at the very core of the spec and my main goal is
>>>> to make sure that this piece remains BW compatible. IOW, any new
>>>> extensions that make life of developers easier are fine (such as
>>>> support for multiple resources with the same path), but incompatible
>>>> changes are not. The matching algorithm simply enforces certain
>>>> programming model that prefers resource and sub-resource methods
>>>> placed directly on the resource to methods discovered via sub-resource
>>>> locators. To put it differently, if one designs a resource class with
>>>> methods for a specific resource (or sub-resource), one should not try
>>>> to additionally extend the set of methods using sub resource locator
>>>> mechanism. If that is required, then ALL the methods must be provided
>>>> using this mechanism. It's a restriction, and again, I understand that
>>>> it may in certain cases come out as confu
>>> sing, but I can see how it makes the code more readable OTOH.
>>>>
>>>>>
>>>>> 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 ?
>>>>
>>>> To that comment I could retort that what you are fighting for is an
>>>> edge case artificially crafted to demonstrate the problem. How many
>>>> users in their would design their resources this way IRL?
>>>>
>>>
>>> Because I know I've advised people before on what happens in such cases.
>>> That is my problem of course, but FYI, I see users using subresource
>>> locators not only as a means to return some instance mapped to some id
>>> (in which case having some sub instance support OPTIONS or HEAD will be
>>> strange), etc, but a way to push some of the code away from the root
>>> resource.
>>> We can forget about HEAD & OPTIONS, but the case where the root has all
>>> the updates, and the subresource - all the retrievals support is very
>>> realistic.
>>>
>>>>>
>>>>> 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.
>>>>
>>>> I propose we fix the bug in the current wording to make the algorithm
>>>> truly BW compatible, then we cool down a bit :) and if we can find
>>>> some real-life use cases to justify the change, we would come up with
>>>> an extension for 2.1 which will be backward compatible and support
>>>> this construct, e.g. by introducing a new special annotation that will
>>>> force the runtime to not exclude the locators or that will make sure
>>>> that @HttpMethod annotations are checked before the locators are
>>>> excluded (even though as I'm writing this I already see the new
>>>> problems with matching Produces/Consumes that will pop up once we
>>>> would make such change, as we're just moving the issue to the next
>>>> matching phase; in any case we will have to carefully think this
>>>> through, this is not a good area for making hasty decisions).
>>>>
>>> Sounds good to me. Lets fix Issue 404 - that will make at least the last
>>> example I quoted work. I'm sure we can use that (i.e, the fact that
>>> under certain conditions the locators are not dropped) as a platform in
>>> the next releases for addressing the last ambiguous spots in the
>>> algorithm :-)
>>>
>>> Thanks, Sergey
>>>
>>> P.S. Please, consider not to get
>>>
>>>> Marek
>>>>
>>>>>
>>>>> 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
>>>>
>>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>>
>> Blog: http://sberyozkin.blogspot.com
>