Hi Ondrej,
These extension points are not really intended for app developers, their main target is framework developers (or in this case JAX-RS implementors). Moreover, in my view, to break ties with JDK’s CompletableStage in your proposal will likely require more work than you anticipate.
It is very likely that JAX-RS 2.1 implementations will support other types beyond CompletableStage right out of the box.
— Santiago
> On Jan 17, 2017, at 4:24 PM, Ondrej Mihályi <ondrej.mihalyi_at_gmail.com> wrote:
>
> Hi Santiago,
>
> My proposal brings 2 advantages:
> - move the clutter from of the alternative rx() methods from the InvocationBuilder one step later, after rx() is called (it is not relevant for those using the default invoker based on CompletionStage)
>
> - to reduce the amount of methods to implement, if an app developer wants to implement a custom invoker - the current solution requires to implement 25 methods in RxInvoker interface, my solution builds on the Rx default invoker and requires only to implement 2 methods ( getCallback(); getUnwrapped();)
>
> I know that for the second point, your vision is that the RxInvoker is implemented by a third party library, but even though, having to implement 25 methods is very inconvenient IMHO. I don't think that alternatives need to implement actual get, post, etc. calls, only how to handle the async result. The InvocationCallback approach in AsyncInvoker is enough, but it is hard to integrate with reactive API.
>
> I'll try to provide an example in couple of days when I have time.
>
> I appreciate that you consider my suggestions, even if they won't be accepted.
>
> Ondrej
>
> 2017-01-17 20:49 GMT+01:00 Santiago Pericasgeertsen <santiago.pericasgeertsen_at_oracle.com <mailto:santiago.pericasgeertsen_at_oracle.com>>:
> Hi Ondrej,
>
> I’m not sure if I fully understand your new proposal. In any case, I fail to see why it is better than the currently proposed one. In fact, at first glance, it seems more complicated if I’m honest.
>
> An actual example using, say, RxJava may help. Otherwise, I think we should continue improving the current approach.
>
> — Santiago
>
>> On Jan 17, 2017, at 12:14 PM, Ondrej Mihályi <ondrej.mihalyi_at_gmail.com <mailto:ondrej.mihalyi_at_gmail.com>> wrote:
>>
>> In fact, on second thought, it's not true we have to have CompletableFuture in the chain at all. The CompletionStage is an interface, which can implement the ability to convert to use any provider. The provider doesn't have to use the CompletionStage at all, we can go deeper and let it implement a custom InvocationCallback instead.
>>
>> I just wanted to make it simple. But if you want to bypass CompletionStage, imagine this (I slightly modified my original proposal):
>>
>> client.request().rx().get(). // we get the RxCompletionStage here, which extends CompletionStage
>> .unwrap(this::provideInvocationCallbackAndRxFlowable) // accepts a producer function, which returns an InvocationCallback AND Flowable, which will be the result of the unwrap method (the 2 return values wrapped in a new container interface)
>> .subscribe(s -> testResult = s, Throwable::printStackTrace);
>>
>> with these definitions:
>>
>> <UNWRAPPED> UNWRAPPED unwrap(Producer<Unwrapper<RESPONSE_TYPE, UNWRAPPED>> unwrapperProvider);
>>
>> and
>>
>> interface Unwrapper<RESPONSE_TYPE, UNWRAPPED> {
>> InvocationCallback<RESPONSE_TYPE> getCallback();
>> UNWRAPPED getUnwrapped();
>> }
>> The producer passed to unwrap() would just need to implement the callback, which forwards to the new UNWRAPPED instance (e.g. Flowable in RxJava2).
>>
>> The invocation callback can be execute mutiple times, making it possible to send multiple events (unlike using CompletionStage), but I don't think that makes sense in REST client.
>>
>>
>> Do you think this could work? Should I try to elaborate further and provide a working example?
>>
>> Ondrej
>>
>>
>> 2017-01-17 17:20 GMT+01:00 Santiago Pericasgeertsen <santiago.pericasgeertsen_at_oracle.com <mailto:santiago.pericasgeertsen_at_oracle.com>>:
>>
>>> On Jan 15, 2017, at 1:37 PM, Pavel Bucek <pavel.bucek_at_oracle.com <mailto:pavel.bucek_at_oracle.com>> wrote:
>>>
>>> I guess the second quiestion is almost reduced to the first one - do we really want to have CompletableFuture ALWAYS in the chain? (or to be more on point - do we want to create JaxRsCompletableFuture and use that as an "rx extension point"?)
>>
>> This is the biggest issue with this proposal, it’s just delegation to CompletionStage, always. This is not the same as the RxInvoker proposal, in which other Rx library can be “natively” integrated.
>>
>> This is a showstopper for me, so -1.
>>
>> — Santiago
>>
>>
>>
>>
>
>