On 23/05/12 17:18, Marek Potociar wrote:
>
> On May 23, 2012, at 5:08 PM, Sergey Beryozkin wrote:
>
>> On 23/05/12 15:40, Marek Potociar wrote:
>>>
>>> On May 23, 2012, at 2:06 PM, Sergey Beryozkin wrote:
>>>
>>>> On 23/05/12 12:15, Marek Potociar wrote:
>>>>>
>>>>> On May 22, 2012, at 11:01 PM, Sergey Beryozkin wrote:
>>>>>
>>>>>> Just one comment,
>>>>>> On 22/05/12 18:16, Marek Potociar wrote:
>>>>>>>
>>>>>>> On May 22, 2012, at 6:49 PM, Bill Burke wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 5/22/12 11:52 AM, Marek Potociar wrote:
>>>>>>>>>
>>>>>>>>> On May 22, 2012, at 3:06 PM, Bill Burke wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 5/22/12 5:28 AM, Marek Potociar wrote:
>>>>>>>>>>>
>>>>>>>>>>> On May 21, 2012, at 10:35 PM, Bill Burke wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I can see users wanting to add support for different formats in different resource classes. i.e.
>>>>>>>>>>>>
>>>>>>>>>>>> @Path("/root")
>>>>>>>>>>>> @Produces("application/xml")
>>>>>>>>>>>> public class MyRootXmlSupport {}
>>>>>>>>>>>>
>>>>>>>>>>>> @Path("/root")
>>>>>>>>>>>> @Produces("application/json")
>>>>>>>>>>>> public class MyJsonSupport {}
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> One of the main design concepts behind JAX-RS is that it should produce a representation independent model. The above use case just seems artificial to me and goes against the intended best practices.
>>>>>>>>>>>
>>>>>>
>>>>>> IMHO there's nothing wrong in having a dedicated resource handler, root handler, whatever one can call it, allocated to managing a specific resource representation. So MyRootXmlSupport& MyRootJsonSupport are looking OK.
>>>>>>
>>>>>> However, I haven't seen a big demand for multiple root resources sharing exactly the same path. This can actually be easily resolved without any back tracking, but I reckon that a combination of root resources and sub resource locators can often be sufficient to get a similar 'setup'.
>>>>>>
>>>>>> Perhaps if there's some compelling reason to support such a case then may be it can be reviewed
>>>>>
>>>>> The use case of providing optional support for additional resource methods (e.g. SEARCH) that may be e.g. too memory-consuming for minimalistic application deployments is what convinced me to support the construct in the end.
>>>>
>>>>
>>>> Sounds interesting. Do you have some initial ideas on how the matching algorithm may need to be changed ?
>>>
>>> Santiago took AI to look at that. Seems like the wording of the 3.7.2 may need to change quite a bit, but the algorithm should remain essentially the same, except you may need to do a method selection based on all methods from all resource classes that declare the same matching URI template that matched the request URI. Sounds like a bit of work...
>>
>> The question is where does it have to stop so to say. Each root resource may have few matching subresource locators.
>
> Not sure I follow. We are only talking about values of @Path annotations placed directly on the root resource classes. Where do the sub-resource locators come to the picture?
I meant that if we have @Path("root") on both A & B root resources, and
a request uri fragment such as "root/1/2/3" then assuming A has a
subresource locator method with "@Path("1")" then it can become a
candidate for the selection.
>
>> I hope it can be a minimalistic and 'cheap' to implement and support change.
>
> Should be - the only difference is that you may need to "group" all root resource classes with the same URI templates (ideally at deploy-time) and then once you match the template you would process all the methods of the all classes in the group as opposed to processing all the methods of just a single class as it is currently stated in the algorithm.
>
>>
>> Example, if we have two matching methods returning sub resource locators, then the more specific one wins. In fact the same is true for the root resource candidates.
>
> That should be preserved.
>
>>
>> The only case is what to do when the final matching group is equal between the selected candidates. I propose that in this case we go on via every candidate and find the first matching method (HTTP verb + path + media types), ignoring subresource locators. If we have both candidates with possible method candidates, then both method candidates ate compared next and that is it...Lets try to keep it as simple as possible
>
> Not sure I follow here completely. In any case, I do agree we should try to keep the change as simple as possible. That's why the idea is to change just the root resource selection from a single resource to all resources with the same template. So instead of a list of methods from a single class [C1.m1(), C1.m2(), C1.m3()] You would in the next phase of the matching process a list of methods from potentially multiple classes [C1.m1(), C1.m2(), C1.m3(), C2.m1(), C2.m2(), C3.m1()]. But since the relevant processing meta-data are the same regardless of which class each particular method belongs to, the actual method list processing would essentially remain the unchanged.
OK. So effectively we need to group all the methods from all the
matching root resource classes that have the same template value.
My concern was that we'd need to check if a given A subresource can
manage a request before retrying B, but that would not really make sense...
Cheers, Sergey
>
> Marek
>