Ya, I had objections. I don't like how you've duplicated methods into
multiple interfaces or get why we need 3-4 interfaces. IMO, you just
need one core Configurable interface implemented by Client and WebTarget
and passed into Feature/DynamicFeature.
On 10/30/2012 9:47 AM, Marek Potociar wrote:
> 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
> <mailto: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
>> <mailto: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
>>> <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