Yes I know that I can delegate but due to the lot of methods this is a
rather lot of stuff to do in all ResponseBuilder producers which is good for
nothing but the sake of Java. Hence the idea is to provide one common
AbstractXXX that implements all this stuff and releases this burden from the
implementor of ResponseBuilder producers. There is no technical need, it is
just smarter to use.
> -----Original Message-----
> From: Bill Burke [mailto:bburke_at_redhat.com]
> Sent: Montag, 29. Oktober 2012 00:51
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: (Another) proposal on Configuration API
> changes.
>
> 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