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