Thinking more about it, IMHO Invocation.asRequestBuilder has to go.
The reason being is that it allows for two alternative flows doing the
same thing joined.
invocationFlexibility() shows this and I think it's not a very good
idea. First we create a nearly completely initialized invocation and
then we repeat the process, still inside possibly the same chain, the
re-initialization...
Cheers, Sergey
On 25/09/11 18:00, Sergey Beryozkin wrote:
> 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