On 12/13/2011 01:25 PM, Sergey Beryozkin wrote:
> On 13/12/11 12:15, Marek Potociar wrote:
>>
>>
>> On Tue 13 Dec 2011 12:11:49 PM CET, Sergey Beryozkin wrote:
>>> Hi Marek
>>> On 13/12/11 10:59, Marek Potociar wrote:
>>>> Just wanted to add that this functionality is not only focused on some low-percentage use case client extensions. I
>>>> believe it is possible to expect that many users will want to access specifics of Jersey, RestEasy or CXF etc. client
>>>> implementations and configurations in a type-safe way.
>>>>
>>>
>>> I think many users who will migrate to 2.0 client API will be very sensitive about writing unportable code; the
>>> example you shown is technically interesting but I wonder if people will ever write such code,
>>
>> If you properly encapsulate the code using proprietary features/config,
>> there is no reason why to shy away of extensions completely.
>>
>>>
>>> I may be wrong, but a code like this:
>>>
>>> Client client = ...
>>> MyJaxrsImplStack.cast(client).setRequestQueueCapacity(10) is equally 'portable'
>>
>> I believe you miss the fact that your cast may fail if the client
>> instance is not of the expected type. But this is just my rant to this
>> particular solution. As I said previously, there are ways how to use
>> extension even without the API.
>
> That was not a rant at all, just mild objection :-)
> By the way, I'll withdraw my argument about the portability which was wrong,
>
> I've no strong objections to having these interfaces retained; but seems like you and Bill can agree on dropping them
> which is good for me,
What I said is, that if Bill can find more support in EG for removal (ideally some members who represent users
perspective) or if he can propose a reasonable simplified API with the same functionality, I would not object.
(One more rant: In general I wish we had a wider feedback and participation from EG when shaping the API.)
Marek
>
> As I said that example looks OK to me; but if the goal of these interfaces is to make it possible only to set the
> extensions properties in a typed safe way then may be we should let them go if doing so will simplify the client API
>
> Sergey
>
>
>>
>> Marek
>>
>>>
>>> Cheers, Sergey
>>>
>>>> Similarly, clients supporting HTTP protocol extensions (e.g. WebDAV) are another large use case group.
>>>>
>>> That is more interesting, would be useful to see an example from Markus or yourself; just would like to understand if
>>> we should get some setProperties(Map) method instead for various extensions to get configured
>>>
>>> Cheers, Sergey
>>>
>>>> Marek
>>>>
>>>> On 12/13/2011 11:53 AM, Marek Potociar wrote:
>>>>> The idea is that with these interfaces you will be able to provide a fluent common API for a type-safe access to any
>>>>> client extension. The two-phase process (Factory->Builder) is there to enable the ability to type-safely configure the
>>>>> produced custom client before it is built. I took the inspiration in Bean Validation spec. Additionally, the API was
>>>>> supposed to provide injection support for the custom client builder artifacts.
>>>>>
>>>>> In an example, I wanted to make sure users are able to write this (see also in JAX-RS API client examples):
>>>>>
>>>>> ThrottledClient Client = ClientFactory
>>>>> .newClientBy(ThrottledClient.Builder.Factory.class)
>>>>> .requestQueueCapacity(10)
>>>>> .build();
>>>>>
>>>>> The above produces a ThrottledClient instance that uses a blocking queue to throttle the amount of client requests
>>>>> flowing through the client instance (see Staged Event Driven Architecture (SEDA) for more on this concept).
>>>>>
>>>>> Let's analyze the details of the example:
>>>>>
>>>>> ClientFactory.newClientBy(ThrottledClient.Builder.Factory.class)
>>>>>
>>>>> instantiates and possibly injects the factory that returns a typed ThrottledClient.Builder instance. The returned
>>>>> builder exposes a type-safe configuration method...
>>>>>
>>>>> .requestQueueCapacity(10)
>>>>>
>>>>> ... that is used to configure the client instance request queue capacity (note that this capacity is not modifiable
>>>>> once
>>>>> the client instance is created). At last a typed ThrottledClient instance is built and returned
>>>>>
>>>>> .build()
>>>>>
>>>>> so that the instance information can further be accessed in a type safe way (e.g. client.getRequestQueueCapacity()).
>>>>>
>>>>> That's for the explanation of why it is designed the way it is designed.
>>>>>
>>>>> I do not feel too strongly about this part of the API though. There are obviously other ways of achieving at least
>>>>> part
>>>>> of the same functionality even though I have yet to see a solution that would look more elegant in the code (from the
>>>>> user's perspective).
>>>>>
>>>>> To sum up, I like the current API but if you can find more support in EG for removing the API or propose a solid
>>>>> replacement for the functionality covered by the API, I would not stand in your way...
>>>>>
>>>>> Marek
>>>>>
>>>>> On 12/12/2011 02:47 PM, Bill Burke wrote:
>>>>>> Maybe I should give more detail (again):
>>>>>>
>>>>>> * We don't need a set of interfaces the application developer will never see
>>>>>> * The interfaces are redudant. All you really need is to specify a javax.ws.rs.ext.ClientFactory with the class
>>>>>> name of
>>>>>> your impl's factory within it.
>>>>>> * If you want to be able to support extensions (i.e. an extended interface to ClientFactory or Client), then it
>>>>>> should
>>>>>> be left up to the provider how they want to support it. For example, I don't want Resteasy to be forced to use your
>>>>>> interfaces, especially when a typecast or even a constructor invocation would be good enough for this scenario.
>>>>>>
>>>>>> On 12/12/11 8:35 AM, Bill Burke wrote:
>>>>>>> I've already complained about this before and gave in-depth reasons why
>>>>>>> we don't need these interfaces, but can we please remove Client.Builder
>>>>>>> and ClientFactoryBuilder? They are not needed by either the jaxrs
>>>>>>> implementation or the application developer. All logic can be contained
>>>>>>> within ClientFactory or Java EE app server.
>>>>>>>
>>>>>>> I have yet to hear a good reason from you guys why we need this extra
>>>>>>> bloat.
>>>>>>>
>>>>>>> Bill
>>>>>>>
>>>>>>
>>>
>>>