users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: Re: Issues with Configurable and Configuration

From: Bill Burke <bburke_at_redhat.com>
Date: Sat, 09 Mar 2013 08:02:47 -0500

On 3/9/2013 4:10 AM, Marek Potociar wrote:
> On 9. 3. 2013, at 0:19, Bill Burke <bburke_at_redhat.com> wrote:
>
>>
>>
>> On 3/8/2013 5:42 PM, Marek Potociar wrote:
>>>
>>> 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
>>>>
>>>> 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);
>>>
>>> You should code your features defensively and also take care of it in your runtime impl. IMO. Features need to know what other features registered as providers & properties etc. Also users should be able to know what everything is configured in the system IMO.
>>
>> You can't really code defensively for this particular case. This is how withConfig() would be implemented.
>>
>> {code}
>> setProperties(config.getProperties());
>> for (Class clazz : config.getClasses())
>> {
>> Map<Class<?>, Integer> contracts = config.getContracts(clazz);
>> register(clazz, contracts);
>> }
>> for (Object obj : config.getInstances())
>> {
>> Map<Class<?>, Integer> contracts = config.getContracts(obj.getClass());
>> register(obj, contracts);
>> }
>> {code}
>>
>> How exactly would a Feature code defensively for this? It can't. There's no way to delete a registered component, so there would be no way for the Feature to override the already registered one. Plus, because getInstances() returns a set, there's no guaranteed order of instances either so the feature may not even be able to detect it needs to override.
>
> 1. register(feature) doesn't mean that feature.configure(...) is invoked immediately. It's your impl. detail if you are doing it.

Client client = ClientBuilder.newBuilder().register(new Feature()).build();

Response response = client.target("").request().get();

// Feature.configure() has been called
Client client2 =
ClientBuilder.newBuilder().withConfig(client.getConfiguration());

An even better example is the server's Configuration which can
continuously be used to create Clients at runtime.

I'm fine with making it an implementation detail and instead have my
code do a typecast of Configuration within withConfig() to an
implementation specific interface

{code}
    ResteasyConfiguration configParam = (ResteasyConfiguration)configParam;
{code}

But, you need to agree that Configuration, by itself, as-is, can't be
used solely to implement withConfig().

> 2. feature can return false if it thinks that it cannot be enabled properly or if it detects that it was already enabled earlier.
> 3. We do not aspire to automatically mend ill user configurations here. User is still responsible to make sure the provided configuration doesn't clash.
>

Its not ill user configurations. Look at the example above. The
situation can happen with *one* simple Feature.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com