On Oct 25, 2012, at 4:20 PM, Bill Burke <bburke_at_redhat.com> wrote:
> On 10/25/2012 10:02 AM, Marek Potociar wrote:
>>
>> On Oct 25, 2012, at 3:51 PM, Bill Burke <bburke_at_redhat.com> wrote:
>>
>>> configuration() doesn't really belong or is needed on Invocation.Builder. Add property() and remove configuration() entirely, or at least move it to Invocation.
>>
>> Just to better understand your motivation:
>>
>> So you say there's no use case for having a different configuration (other than properties) on a per-request bases if the requests are targeted at the same resource (say a need to have special filters for a hand-shake request but not for the other ones)?
>>
>
> Meh, maybe you're right...but instead of Configuration maybe just add proeprty()/register() methods to Invocation.Builder and move configuration() to Invocation
>
> interface Invocation.Builder {
> Builder property(String name, Object value);
> Builder register(Class<?> clazz);
> Builder register(Object instance);
> ...
> }
:) I just wanted to write you that I gave it more thought and your original proposal LGTM (remove configuration(), add property(...)).
Anyway... I am now working on updating my earlier proposal on config API changes... And I'm thinking that what we could actually do is:
Decouple client.Configuration from core.Configurable. This is to ensure both APIs can be specialized as they need as well as to make sure nobody is trying to pass client-side Configuration instance into a Feature instance directly.
Rename core.Configurable to core.RuntimeConfig.
Rename client.Configuration to client.Configured (...bear with me :))
Let Client, WebTarget, Invocation and Invocation.Builder all extend client.Configured and customize the return values in each of these classes to retain the API fluency.
Remove the configuration() getter method from all client-side APIs.
That way we get the more API fluency even in cases when configuration is involved, which seems to be particularly important for your request building use case. Also, we'll still be able to easily create new clients configured in a same way as any of the existing client-side components.
I took a stab on it and put it on github into my private jax-rs repo under config-api branch (I figured that way I can present unapproved proposals without pissing off Sergey by making commits into java.net repo...) - please have a look:
https://github.com/mpotociar/jax-rs/compare/config-api
>
>> Also, what is your use case for modifying properties? Would it make sense to implement that use case via features or provider instances?
>>
>
> Specifying request QoS properties, like how long you want to wait for a response. Setting a Public/PrivateKey or other objects that might be used by a filter/interceptor.
I see. Thanks.
Marek
>
> Bill
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com