What additional methods does RuntimeConfig have over Configured? What
additional methods does Configuration have over Configured? I could not
see a difference. So, why do we need two separate things?
So, you just want to have these separate things because a user might try
to configure a Feature or DynamicFeature manually? Come on, that is
just totally ridiculous. You must have some really dumb users on the
Jersey side. IMO, you've made it much more confusing.
Initially what I thought you were doing was separating
getProviderClasses() from registration. And have like a client-side
APplication class. But this is not what you're doing.
I just don't think what you've done improves things. But, I've known
you long enough to know you have your mind set. -1 from me, not that it
matters...
On 10/31/2012 6:17 AM, Marek Potociar wrote:
>
> On Oct 30, 2012, at 7:18 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>> Ya, I had objections. I don't like how you've duplicated methods into multiple interfaces or get why we need 3-4 interfaces.
>
> Well, I tried to explain and never heard back from you until now when it seems I failed to explain the reasons properly, as you just repeat the same objections... So let me try again.
>
> Please check the code carefully. I did NOT duplicate anything! I'm extending a Configured interface and merely overriding the return values to keep the APIs fluent (ugly and less extensible alternative would involve making the Configured interface generic...). Also, I did NOT add any new classes or interfaces.
>
>> IMO, you just need one core Configurable interface implemented by Client and WebTarget and passed into Feature/DynamicFeature.
>
> Actually, that essentially is what I do... I extend the former client.Configuration interface that has been renamed to Configured by Client, WebTarget, Invocation.Builder, Invocation.
>
> As I explained, people were confused and tried to configure features manually instead of just registering them. Thus there was a need to decouple the Configurable and client.Configuration. Now it's decoupled. There is RuntimeConfig (Configurable) and client.Configured (client.Configuration).
>
> RuntimeConfig is used by Feature and DynamicFeature and is otherwise not exposed from client APIs. I'm also considering supporting injection of an immutable RuntimeConfig on server side. And to me "@Context RuntimeConfig config" looks better and more meaningful than "@Context Configurable configurable" which does not look like something read-only at all. Also, RuntimeConfig has methods targeted at intended deployment/runtime initialization use cases (isEnabled/isRegistered/register...).
>
> client.Configured is now an interface extended by main client API components (Client, WebTarget, Invocation.Builder, Invocation). It has methods specific for client-side component configuration. It has methods that enable sharing and copying configuration between components (updateFrom, getProviderClasses, getProviderInstances). Additionally, I order to make sure that Configured.register(...) methods do not break the fluent flow, the extending components override the return value for these methods.
>
> I was able to make the change above without introducing any additional interfaces to the API. And I believe I improved the API.
>
> Marek
>
>>
>> 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
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com