Certainly it is not hard to implement, but it is a "source code desert" in
the end. What I try to reach is simply to make the API more user friendly.
From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
Sent: Montag, 29. Oktober 2012 11:42
To: jsr339-experts_at_jax-rs-spec.java.net
Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: (Another) proposal on
Configuration API changes.
On Oct 28, 2012, at 9:22 AM, Markus KARG <markus_at_headcrashing.eu> 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.
I think with the modern IDEs that provide "Delegate method" intentions it
should not be that hard to implement. Since we do not expect many users
extending the target, adding abstract classes to the API seems to be an
overhead to me. Not sure what others think.
Marek
Regards
Markus
From: Marek Potociar [mailto:marek.potociar@ <
http://oracle.com> oracle.com]
Sent: Samstag, 27. Oktober 2012 18:17
To: <mailto:jsr339-experts_at_jax-rs-spec.java.net>
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 <
http://java.net/>
java.net repo...) - please have a look:
<
https://github.com/mpotociar/jax-rs/compare/config-api>
https://github.com/mpotociar/jax-rs/compare/config-api
Comments are welcome.
Marek