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
2) ClientBuilder.withConfig(Configuration) still has issues. If
Configuration.getInstances() and getClasses() returns any providers
registered by Features, they you have some potentially weird problems of
a provider being doubly registered.
For example, if you call this in a feature:
configurable.register(MyFilter.class, Priorities.AUTHENTICATION);
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com