users@jax-rs-spec.java.net

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

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Tue, 30 Oct 2012 14:47:24 +0100

To clarify, I have received a comment from Markus and a couple of questions from Bill. But those did not seem to be in a form of an actual objections. I'd like to hear from the other members of this EG too. If you don't write anything because you're fine with the change, please change that behavior, a support or positive feedback is welcome too. At least I know you're following our discussions. A sleeping member is useless member...

Marek

On Oct 30, 2012, at 2:43 PM, Marek Potociar <marek.potociar_at_oracle.com> wrote:

> Hello experts,
>
> I have not received any negative feedback so far on the proposed Configuration API change. Please send me your feedback by Thursday CoB. Unless I hear any objections, I plan to push the change to master repository on Friday.
>
> Thanks,
> Marek
>
>
> On Oct 27, 2012, at 6:17 PM, Marek Potociar <marek.potociar_at_oracle.com> 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 java.net repo...) - please have a look:
>>
>> https://github.com/mpotociar/jax-rs/compare/config-api
>>
>> Comments are welcome.
>>
>> Marek
>