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
> <mailto: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
> <mailto: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
> <mailto: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
>