Hello Marcus,
I most likely don't understand what exactly you are proposing here. Can
you please describe your proposal in more detail?
If the code sample you provided should be implemented, we'd need to
return new set of ifaces starting from Client.newClient. It seems like
you are re-trying to bring up the idea about having RxClient and not
modifying existing one.
Thanks and regards,
Pavel
On 21/01/2017 08:35, Markus KARG wrote:
>
> Pavel,
>
> no, this is not a type. The code sample shows that reactive
> programming is possible already with JAX-RS 2.0 when done /explicitly/
> by the application programmer, so the code improvement I suggested
> should work not only with the new RX support, but also with "plain"
> /async/ support.
>
> When addressing the Executor topic, there is one more issue to check
> https://java.net/jira/browse/JAX_RS_SPEC-461. I filed it back in 2014,
> and it is covering the same issue.
>
> -Markus
>
> *From:*Pavel Bucek [mailto:pavel.bucek_at_oracle.com]
> *Sent:* Freitag, 20. Januar 2017 19:30
> *To:* jsr370-experts_at_jax-rs-spec.java.net
> *Subject:* Re: Proposal for RX API Improvement
>
> Hi Marcus,
>
> that was already brought by Adam, just after we started - see
>
> https://java.net/projects/jax-rs-spec/lists/jsr370-experts/archive/2017-01/message/16
> https://java.net/jira/browse/JAX_RS_SPEC-523
>
> I plan to tackle that right after we are finished with Rx Client and
> maybe SSE, since that will most likely have wider impact (not limited
> to reactive support) and I'd like to have it made for the whole API at
> once.
>
> (your code sample does not contain rx() method in the chain - I hope
> that's just a typo. I believe when the executor service is set, it
> should be used for all async operations, including AsyncInvoker,
> RxInvoker and possibly NioInvoker (whatever that will be)).
>
> Best regards,
> Pavel
>
> On 20/01/2017 19:12, Markus KARG wrote:
>
> Experts,
>
> the proposed RX API allows to explicitly provide an Executor.
>
> I assume that typical applications will only use one or two
> Executors, and typically a Java EE application will always use the
> Default Managed Executor Service of the container.
>
> So maybe it would be a good idea if we can get rid of repeating
> the Executor again and again for each invocation, and provide an
> optional way to set a "Default Executor" directly with the Client
> instance?
>
> final Client client =
> ClientBuilder./newClient/(MY_IO_BOUND_EXECUTOR); // /overriding/
> implicit default executor
>
> final CompletableFuture<String> getA = client.target("some uri
> A").request().get(); // /using MY_IO_BOUND_EXECUTOR/
>
> What do you think?
>
> -Markus
>