users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: UriBuilder.fromMethod

From: Bill Burke <bburke_at_redhat.com>
Date: Thu, 05 Sep 2013 07:45:04 -0400

On 9/5/2013 5:31 AM, Marek Potociar wrote:
> Hi Jan,
>
> On Aug 8, 2013, at 10:09 PM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>
>> Bill,
>> thanks for clarifying.
>>
>> On 08.08.2013, at 14:37, Bill Burke <bburke_at_redhat.com> wrote:
>>
>>> This is correct behavior. the TCK tests this. Supposedly there are cases where you just want the @Path annotation from the method and not the path and the method.
>>
>> Ah - and what would they be? Any idea?
>
> Lets first clarify the purpose of UriBuilder: UriBuilder is not a fancy high-level utility that would introspect resources or inspect resource graphs or change behavior based on the context in which it is used. As such, UriBuilder is pretty much just doing what it says - it builds URIs based on the provided information. Knowing about the path annotation, it provides convenience methods to retrieve the information from the path annotation applied to a particular annotated element passed as an input to the URI builder, but nothing else.
>
> As for the use cases for current behavior, some root resources can be accessed also as sub resources. Some resources can implement a common resource interface and expose it via different root paths. In these scenarios, automatically applying the class-level Path value would not be desirable.
>
> FWIW, I am not against coming up with a new convenience method that would cover your use case as such - IIRC, EG was however against introducing another method in the already large UriBuilder API. I am also not against coming up with a method that would not fail with an exception in case there is no Path annotation on the input annotated element, as Bill would want - I'm just saying that we cannot change the behavior of the API method that is already there.
>

The only backward compatibility you are guarding against is the TCK's as
this is the only thing that would be dependent on the method throwing an
exception. Tweaking the behavior of the existing method would not
effect any user's application. You changed something as complicated as
the Request matching algorithm in 2.0, but won't make this tiny,
intuitive change for 2.1?

In this particular case, I want to be able to use UriBuilder to build
links that are not hardcoded URLs, but instead driven by the
application. Sucks that if I refactor my @Path's around that a once
working UriBuilder could possibly not work anymore...

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com