A user came across this, that's why I'm posting.
On 7/17/2013 10:20 AM, Sergey Beryozkin wrote:
> FYI, I'm not considering this being a critical issue, but I start
> missing some debate, so here I am with the comments :-)
>
> Sergey
>
>
> On 17/07/13 15:17, Sergey Beryozkin wrote:
>> On 17/07/13 14:52, Marek Potociar wrote:
>>> The javadoc is clear:
>>>
>>> "Append a path from a *Path-annotated method*..."
>>>
>>> IMO the current API is not meant to work with methods that do not have a
>>> @Path annotation. Also, there is no default path value defined for a
>>> resource method in general. Think of sub-resources and resource
>>> inheritance hierarchies.
>>>
>>
>> Sure, if we have:
>>
>> @Path("/root")
>> public class Foo {
>> @GET
>> public String get() {}
>> }
>> }
>>
>> Then adding @Path("") to get is redundant, get() inherits a Class level
>> Path value.
>>
>> get() is invoked when "/root" is used, so throwing an exception in
>>
>> uriBuilder.path(Foo.class).path(Foo.class, "get")
>>
>> is wrong IMHO, because "get" is meant to respond to "/root" calls
>>
>> Cheers, Sergey
>>
>>> That said, if TCK does not test this, we could try to see if we can
>>> solve it by clarifying javadoc and updating RI. OTOH, if current TCK
>>> does test this behavior, one of you would need to submit an official TCK
>>> challenge.
>>>
>>> Marek
>>>
>>> On Jul 17, 2013, at 2:19 PM, Sergey Beryozkin <sberyozkin_at_talend.com
>>> <mailto:sberyozkin_at_talend.com>> wrote:
>>>
>>>> Hi, my understanding is that
>>>>
>>>> uriBuilder.path(Foo.class).path(Foo.class, "get") should produce
>>>> "/root" as opposed to getting an exception thrown because no @Path
>>>> exists at get();
>>>>
>>>> Throwing an exception with get() having @GET is what the problem is,
>>>> because we actually have a default Path value there
>>>>
>>>> Cheers, Sergey
>>>> On 17/07/13 13:08, Marek Potociar wrote:
>>>>> Hi Bill,
>>>>>
>>>>> Sure, please log the Jira.
>>>>>
>>>>> Just to be clear - what you suggest is adding new method that would
>>>>> be "safe", not changing behavior of the existing method that is
>>>>> enforced by TCK, right?
>>>>>
>>>>> Marek
>>>>>
>>>>> On Jul 15, 2013, at 2:54 PM, Bill Burke <bburke_at_redhat.com
>>>>> <mailto:bburke_at_redhat.com>> wrote:
>>>>>
>>>>>> UriBuilder path(Class resource, String method);
>>>>>>
>>>>>> IMO, this method should do nothing if there is a a http method
>>>>>> annotation on the Java method. Right now, the method throws an
>>>>>> exception if no @Path is on the Java method. (I think the TCK tests
>>>>>> this too).
>>>>>>
>>>>>> The case would be this:
>>>>>>
>>>>>> @Path("/root")
>>>>>> public class Foo {
>>>>>>
>>>>>> @GET
>>>>>> public String get() {}
>>>>>> }
>>>>>>
>>>>>>
>>>>>> uriBuilder.path(Foo.class).path(Foo.class, "get").build();
>>>>>>
>>>>>>
>>>>>> This points to the java method you want and ensures that if a @Path
>>>>>> is added in the future to the get() method, the appropriate path
>>>>>> gets generated still.
>>>>>>
>>>>>> If you agree I'll log a jira.
>>>>>>
>>>>>> --
>>>>>> Bill Burke
>>>>>> JBoss, a division of Red Hat
>>>>>> http://bill.burkecentral.com
>>>
>>
>>
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com