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 [mailto:marek.potociar_at_oracle.com]
> *Sent:* Samstag, 27. Oktober 2012 18:17
> *To:* jsr339-experts_at_jax-rs-spec.java.net
> *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 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