https://java.net/jira/browse/JAX_RS_SPEC-545
https://java.net/jira/browse/JAX_RS_SPEC-546
https://java.net/jira/browse/JAX_RS_SPEC-547
:-)
-Markus
From: Pavel Bucek [mailto:pavel.bucek_at_oracle.com]
Sent: Montag, 23. Januar 2017 17:50
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: [jax-rs-spec users] Re: Proposal for RX API Improvement
Hi Markus,
please file an issue, as I already suggested.
I'm not saying it is not related, but it's out of scope of "Reactive Client API". I'll happily mark that issue as 2.1-candidate.
Best regards,
Pavel
On 22/01/2017 13:42, Markus KARG wrote:
Sorry for the confusion. There are two separate improvement proposals:
* One talks about getting rid of @Suspend AsyncResult by allowing CompletableStage as return type. I wanted to say that there is no typo in THAT proposal.
* This one, which simply proposes that the default executor used inside of JAX-RS can be replaced by the application programmer at time of client creation already. My idea is NOT to warm up RxClient again, and yes, the code below definitively misses the rx() method if one interprets it as a diff to the API as it is discussed currently. In fact, the code was taken from a very old slide of mine, when no RX proposal was on the table). See, we are continuing discussions that startet more than three years ago. BTW, this proofs that not even Adam was the first to ask for this DAYS ago, but it was me YEARS ago… ;-)
We should really discuss proposals IN JIRA, or strictly separate the MAIL SUBJECTs somehow… Anyways, please do not just read the java code in my emails, it most likely is pseudo code. It is much better to read my textual explanations, or just the code comments… ,-)
Sorry for that!
-Markus
BTW, there is C in my name. ;-)
From: Pavel Bucek [mailto:pavel.bucek_at_oracle.com]
Sent: Sonntag, 22. Januar 2017 11:27
To: ondrej.mihalyi_at_gmail.com; jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: [jax-rs-spec users] Re: Proposal for RX API Improvement
If you read the thread carefully, you'll see that I already pointed out that there is no rx() method invocation and Marcus replied that it is intentional. Thus my response sent earlier today.
Have a nice weekend! :)
Pavel
On 22/01/2017 11:20, ondrej.mihalyi_at_gmail.com wrote:
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 <mailto:pavel.bucek_at_oracle.com>
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