Other than the fluency, what exactly does this accomplish? You have
duplicate methods in each of these interfaces.
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.
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