On Jul 17, 2013, at 4:09 PM, Bill Burke <bburke_at_redhat.com> wrote:
> IMO, this should be challenged (if TCK tested) as it was an oversight of the API designer.
Why do you think so? The javadoc of this method seems to specifically address this use case - if there is more than one or less than one Path-annotated method with the name in the class, the method is mandated to raise the exception. This is also exactly what JAX-RS 1.1 TCK is testing.
> The whole point of these path() methods was so that the uribuilder wouldn't have to know the structure of the URI it was creating.
Not sure I follow. The UriBuilder path methods are lower-level API meant to conveniently retrieve path information from various parts of Path-annotated resources (classes, methods). Why do you think that in the current version of the API the UriBuilder would need to know the structure of the URI?
IMO, what your user asks for is a more "higher-level" API, that would be more forgiving, and I do understand why. I'm however slightly concerned about where we should draw the line in terms of exposing new convenience methods.
Marek
> On 7/17/2013 9:52 AM, 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.
>>
>> 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