On Oct 29, 2012, at 12:48 AM, Bill Burke <bburke_at_redhat.com> wrote:
> Other than the fluency, what exactly does this accomplish?
You wanted to set properties on Invocation.Builder directly didn't you? This proposal enables that as well as makes the API more fluent. Also, decoupling of Configuration and Configurable prevents users from trying to manually invoke Feature.configure(...) methods, which already seems to be causing some confusion among early adopters.
> You have duplicate methods in each of these interfaces.
I do not. I merely override the return type to retain the fluency.
> I'd say have one *core* interface, Configurable, that is extended by WebTarget and Client and fluentized , and that is passed into Feature and DynamicFeature as a parameter.
In the full context of your email, I don't follow your suggestion. Isn't my proposal doing what you are asking for? Perhaps you're referring to the fact that Configuration and Configurable are split? In that case, the change has been made as Configuration had to provide some extra methods on top of Configurable anyway. Also, this decoupling prevents users from trying to manually invoke Feature.configure(...) passing in a web target etc (see above).
Marek
> On 10/27/2012 12:17 PM, Marek Potociar wrote:
>> Hello experts,
>>
>> I'm starting a new thread using a text that I already replied to Bill on
>> one of our email threads, but I'm worried some of you may miss it. So
>> here it goes again:
>>
>> 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
>> <http://java.net/> repo...) - please have a look:
>>
>> https://github.com/mpotociar/jax-rs/compare/config-api
>>
>> Comments are welcome.
>>
>> Marek
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com