jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: Update in the client configuration API flow

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Sun, 25 Sep 2011 18:00:12 +0100

Hi Marek

here are some comments:

- a form(...) entity qualifier in the example showing post(form(new
Form(...)))
seems redundant given that Form is a dedicated class capturing a form
submission

- example invocationFlexibility concerns me a bit.

I've checked the source and I see no accept() method at all -
Invocation.Builder has a header(...) method, so I can use it.
Target allows for

target.request()
and
target.request(acceptMediaTypes)

The former option requires me to do header("Accept", "text/xml") but
still lets me do acceptLanguage(...). And if Request.RequestBuilder did
have accept() then

target.request().buildGet().asRequestBuilder().accept("text/html").invoke()

vs

target.request(acceptMediaTypes).get();


seems 'unfair' toward target.request() :-).
Can we have accept() on Invocation.Builder ?

Cheers, Sergey



On 20/09/11 15:30, Marek Potociar wrote:
> Hello experts,
>
> Please review the proposed change I have just commited:
> http://java.net/projects/jax-rs-spec/sources/git/revision/f48ae3d9a98a6194df3abe708347083bf78afc91
>
> The change branches off the configuration flow of client-side artifacts from the main request-to-response execution
> flow. From my recent discussion with Sergey on this list as well as from further feedback I have received privately it
> seems the mixed mutable and immutable methods on Targets may indeed cause some user confusion.
>
> To reduce the confusion we decided to make Target "dirty" immutable - Target will not expose any methods that would
> return same Target instance, however Target's configuration state can be indirectly modified (in a separate method flow)
> by accessing its Configuration instance and invoking mutators on that instance. Configuration interface is a
> rename/replacement for former Configurable<T> interface. Please, look at the samples, they should be rather
> self-explanatory.
>
> We decided to use this solution because it allows for keeping the Target immutable wrt. URI which helps us preserve
> URI-based identity contract (equals/hashCode) and makes it possible to use Target instances safely with e.g. Java
> collection classes etc.
>
> Kind regards,
> Marek
>
>


-- 
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com