I think that Marcus’ code really contains errors, but in different place than you both think 🙂
Marcus forgot to call either async() or rx(), and used CompletableFuture, which is supported only by rx() now ( asyncInvoker supports Rx via the invocationCallback).
But what Marcus proposes makes sense, and it’s already covered by both JIRA issues. Both async and Rx use executors, it makes sense to define a default executor for the client, regardless if async or Rx API is used to issue the call later. It would also help in asyncInvoker, as currently there’s no way to provide an executor in any standard way, an e.g. in GlassFish, asyncInvoker will use a non-managed thread from JavaSE.
Ondrej
Od: Pavel Bucek
Odesláno:neděle 22. ledna 2017 10:23
Komu: jsr370-experts_at_jax-rs-spec.java.net
Předmět: [jax-rs-spec users] Re: Proposal for RX API Improvement
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