users@jax-rs-spec.java.net

[jax-rs-spec users] Re: [PLEASE REVIEW] JAX-RS Client Reactive API -- updated

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Wed, 1 Feb 2017 13:17:57 +0000

Hi Pavel

I've just updated the CXF master to m03, and the Rx client API
looks/fits well.

It's unfortunate we can't type something like

.rx(Observable.class)

by giving rx() a native Rx class like Observable.class, etc, but I
appreciate it proved too tricky to implement this style, though please
revisit
this issue when you get a chance, I might try too.

The only semi-open issue for me here is to investigate if implementing
RxInvoker with the help of the non-blocking async HTTP transport can
prove somehow beneficial compared to just letting the Rx framework pool
manage the sync invocation.
I'm rusty on these low-level HTTP mechanics, so it will take sone time,
but I'd like to keep this option of possibly providing more than SyncInvoker
to RxInvoker providers kept open - this in itself is a minor issue as
far as the overall JAX-RS 2.1 API support for Rx is concerned

Thanks, Sergey


On 20/01/17 14:12, Pavel Bucek wrote:
> Dear experts,
>
> thanks for your feedback!
>
> Last suggestion by Santiago (doing lookup by the RxInvoker subclass)
> is implementable and I believe it is the best one we do have.
>
> Code example (extensibility support):
>
> Client rxClient =client.register(CompletionStageRxInvokerProvider.class, RxInvokerProvider.class);
>
> CompletionStage<List<String>> cs =
> rxClient.target("remote/forecast/{destination}")
> .resolveTemplate("destination","mars")
> .request()
> .header("Rx-User","Java8")
> .rx(CompletionStageRxInvoker.class)
> .get(new GenericType<List<String>>() {
> });
>
> cs.thenAccept(System.out::println);
> Corresponding pull request: https://github.com/jax-rs/api/pull/3
> Please review the pull request and provide your comments and suggestions.
>
> Thanks and have a nice weekend,
> Pavel
>
>
>
> On 19/01/2017 16:54, Santiago Pericasgeertsen wrote:
>> Hi Pavel,
>>
>> Just catching up with this issue. I guess the two levels of
>> indirection has led us into a generic wall :)
>>
>>
>>> Client rxClient =
>>> client.register(CompletionStageRxInvokerProvider.class);
>>> CompletionStage<UserPojo> cs =
>>> rxClient.target("http://foo.bar")
>>> .request()
>>> .rx(CompletionStage.class)
>>> .get(UserPojo.class);
>> So what if we reduce indirection and write:
>>
>> .rx(CompletionStageRxInvoker.class)
>>
>> as before, still keeping the provider for it? Less ideal of course.
>>
>> — Santiago
>>
>