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.
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> 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> 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