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

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

Don't see why we need an AbstractXXX in the spec. #1 it exposed too
much implementation details, and #2, your WebDavTarget can just delegate
to a real WebTarget.

On 10/28/2012 4:22 AM, Markus KARG wrote:
> No objections. The examples look much more fluent indeed. What is not so
> nice is that WebDavTarget now has to implement lots of methods that
> actually are not in any way different from their vanilla HTTP
> counterparts (for which a JAX-RS implementation already brings an
> implementation with it). If there would be some common abstract
> implementation (hence: class WebDavTarget extends AbstractWebTarget,
> with the latter providing a common implementation of all that
> configuration methods that are shared by http and WebDav WebTargets)
> this would make it much easier to extend the Client API.
> Regards
> Markus
> *From:*Marek Potociar []
> *Sent:* Samstag, 27. Oktober 2012 18:17
> *To:*
> *Subject:* [jsr339-experts] (Another) proposal on Configuration API changes.
> 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