[jax-rs-spec users] [jsr339-experts] Re: (Another) proposal on Configuration API changes.

From: Bill Burke <>
Date: Sun, 28 Oct 2012 19:48:57 -0400

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
> <> repo...) - please have a look:
> Comments are welcome.
> Marek

Bill Burke
JBoss, a division of Red Hat