On Mar 8, 2013, at 11:34 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> On 3/8/2013 12:25 PM, Marek Potociar wrote:
>>
>> On Mar 8, 2013, at 4:52 PM, Marek Potociar <marek.potociar_at_oracle.com> wrote:
>>
>>>
>>> On Mar 7, 2013, at 11:34 PM, Bill Burke <bburke_at_redhat.com> wrote:
>>>
>>>> #1 Do you really want somebody calling replaceWith() within Feature.configure() or DynamicFeature.configure()? IMO, replaceWith() should be moved to ClientBuilder, Client and WebTarget and not be part of Configurable. (Or even removed from the API and deferred to a later release)
>>>
>>> I'm fine with making it part of client component APIs. I'm strongly against removing from the API. Your issue has been targeted for 2.0.
>>
>> I gave it another look and I'm actually not against against removing the replaceWith() altogether. I could not find any use case in our code to justify keeping it there. Of course, we would have to keep some similar method on the ClientBuilder API.
>>
>> I'm going to remove the replaceWith() method completely (sans new method on ClientBuilder) unless anybody objects...
>>
>
> I talked about this in JIRA too.
>
> 1) Invocation.Builder still needs to set properties whether it implements Configurable or not
I assume you refer to issue #385. I'd be fine with having per-request property setter on both Invocation and Invocation.Builder.
But that's something that should not be mixed with per-client runtime configuration properties, right? Note that these request-scoped properties are exposed to providers via request contexts. IOW, it's not the same thing as runtime-wide Configuration properties.
Marek