2017-01-13 22:36 GMT+01:00 Evaldo Antonio Pinto Junior <
evaldoapjunior_at_gmail.com>:
>
> I did not understand the CompletableStage, and i may be asking the wrong
> question.
> The use of the CompletableStage is to obtain an Asynchronous IO return of
> the JAX-RS Service ?
>
Yes, but you can obtain Asynchronous IO already using async(). Using
CompletionStage makes it possible to write readable, fluent code, in a
reactive way.
Compare what you can do today with what might be possible with rx()
returning CompletionStage:
JAX-RS 2.0:
client.request().async()
.get(new InvocationCallback() {
publlic void completed(RESPONSE) {...}
public void failed(Exception) {...}
});
Proposed in JAX-RS 2.1:
client.request().rx()
.get()
.thenAccept( response -> { ... })
.exceptionally( e -> { ... });
You could even chain multiple REST invocations (or any actions returning
CompletionStage):
client.request().rx().get()
.thenCompose( response -> {
return client.path(response.getNextPath())
.request().rx()
.get();
})
.exceptionally( e -> { ... });
A nice side effect is that you can define only one exception handler for
all the invocations.
Ondrej
>
> Regards,
>
>
> Evaldo Junior
>
>
> ---------- Mensagem encaminhada ----------
> From: Evaldo Antonio Pinto Junior <evaldoapjunior_at_gmail.com>
> To: jsr370-experts_at_jax-rs-spec.java.net
> Cc:
> Date: Fri, 13 Jan 2017 05:45:06 -0200
> Subject: Re: [jax-rs-spec users] Re: JAX-RS 2.1 - work schedule
> I am novice to the JSR group. I did not understand the CompletableStage,
> and i may be asking the wrong question.
> The use of the CompletableStage is to obtain an Asynchronous IO return of
> the JAX-RS Service ?
>
>
> Evaldo Junior
>
> 2017-01-12 18:03 GMT-02:00 Sergey Beryozkin <sberyozkin_at_talend.com>:
>
>> Have a look please at the proposed API, rx() is simply a bridge into a
>> CompletableStage, while another rx(...) overload (which I have some
>> separate techincail issues with) will let users plug-in other reactive
>> implementations, while still working with JAX-RS 2.1 API - only a type
>> variable will differ. IMHO it is critical JAX-RS stays more open (rx() and
>> rx(...) is a good example)
>>
>> Sergey
>>
>>
>> On 12/01/17 19:06, Sergey Beryozkin wrote:
>>
>> Standards, standards. You keep forgetting that today many users do not
>> care about standards but about being able to use the good, proven to work
>> technologies in their work.
>> We should learn from Spring WS/REST.
>>
>> > In the end, what we decide, is frozen for decades. I mean, that's a
>> difference between breeding an international standard and simply providing
>> a good API _for now_.
>> The standard which noone will use ? rx() will not force people to use
>> what you do not consider a proper standard
>> On 12/01/17 18:53, Markus KARG wrote:
>>
>> RxJava is not a JCP standard, and popularity can change easily. So it is
>> doubtful whether non-standards have to be taken core of by standards. I
>> cannot see any other JCP standard that enforces a detour in the API just
>> for the sake of supporting non-standards. Correct me if I am wrong. A
>> better way would be defining an SPI, or configuration, too statically
>> choose in the bootstrat. I doubt that applications will mix differen RX
>> implementations at runtime, so there is no need to say "I want RxJava" with
>> every single call of the API.
>>
>>
>>
>> Yes, Java 10. I heared that it might provide an official RX standard for
>> Java SE. So JAX-RS "3+" might be facing a situation whethere it has to
>> support an official standard. We have to take care that decisions for
>> JAX-RS today must not stand in the way of usefulness and conciseness of
>> JAX-RS in the future. I hardly think that in two or three years people like
>> the idea that they have to write "rx(Classname)" always if possibly Java
>> 10's reactive API took over and nobody talks about CompletableStage and
>> RxJava anymore.
>>
>>
>>
>> In the end, what we decide, is frozen for decades. I mean, that's a
>> difference between breeding an international standard and simply providing
>> a good API _for now_.
>>
>>
>>
>> Markus
>>
>>
>>
>> *From:* Sergey Beryozkin [ <sberyozkin_at_talend.com>
>> mailto:sberyozkin_at_talend.com <sberyozkin_at_talend.com>]
>> *Sent:* Donnerstag, 12. Januar 2017 18:56
>> *To:* jsr370-experts_at_jax-rs-spec.java.net
>> *Subject:* Re: [jax-rs-spec users] JAX-RS 2.1 - work schedule
>>
>>
>>
>> Java 10 ? JAX-RS 2.1 is Java 8 based, and RxJava is highly popular so
>> voluntarily restricting 2.1. to CompletableStage only would be a mistake...
>> Sergey
>> On 12/01/17 17:10, Markus KARG wrote:
>>
>> The question is whether we actually want the ability to support other
>> reactive implementations, or whether we decide to stick with
>> CompletableStage? The rx intermediate method makes the API more complex for
>> anybody. On the other hand, Java 10 possibly will provide a "real" reactive
>> API for everyone, and we cannot natively support it, but enforce people to
>> use rx() still, which is tedious. I cannot remember that the EG actually
>> agreed upon a final answer of this dilemma.
>>
>>
>>
>> *From:* Santiago Pericasgeertsen [ <santiago.pericasgeertsen_at_oracle.com>
>> mailto:santiago.pericasgeertsen_at_oracle.com
>> <santiago.pericasgeertsen_at_oracle.com>]
>> *Sent:* Donnerstag, 12. Januar 2017 16:00
>> *To:* jsr370-experts_at_jax-rs-spec.java.net
>> *Subject:* Re: [jax-rs-spec users] JAX-RS 2.1 - work schedule
>>
>>
>>
>>
>>
>> On Jan 11, 2017, at 4:17 PM, Pavel Bucek <pavel.bucek_at_oracle.com> wrote:
>>
>>
>>
>> So what's going to happen next? We are currently working in PoC
>> implementation of Reactive client API which is currently in the JAX-RS
>> source repository master branch - it is almost ready for review. We
>> identified small improvement needed there and I'm going to take care of
>> that, finish the PoC implementation and document the API on the wiki. Once
>> this is done, I'll send a request for review to this mailing list.
>>
>>
>>
>> Just a quick reminder that the crux of the RX work is the addition of
>> new rx() methods to Invocation, with default support for CompletionStage
>> and an extension point to plug in other reactive implementations via the
>> RxInvoker type [1].
>>
>>
>>
>> — Santiago
>>
>>
>>
>> [1] https://java.net/projects/jax-rs-spec/sources/api/conten
>> t/jaxrs-api/src/main/java/javax/ws/rs/client/Invocation.java
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>