Hi Sergey,
thanks for your feedback.
I agree that rx(Observable.class) would be nicer, but I really don't see
how could we do that right now. :-/
Ad sync/async invoker in the RxInvokerProvider# getRxInvoker .. the only
issue I saw was related to the executor service. Jersey has the feature
to set the executor service for Async Invoker and since I don't want to
have direct dependency on Jersey, I can't touch that executor service.
So the Jersey implementation is (as others) waiting for the global
settings for executors in this area.
I haven't seen anything else yet, but I can imagine something will come
up - please let us know if you'll discover something.
Thanks and regards,
Pavel
On 01/02/2017 14:17, Sergey Beryozkin wrote:
> 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
>>>
>>
>