>
> So the users will have to register somewhere else the factories, how will
> they do it and where is a win, in terms of the simplification ?
>
Wouldn't ClientBuilder.newClient(Configuration) provide a suitable place to
define RxInvokerProviders? Or a new method in ClientBuilder?
The simplification is that the developer can create her own static method
to get a new client and use it everywhere.
Ondrej
2017-01-14 11:41 GMT+01:00 Sergey Beryozkin <sberyozkin_at_talend.com>:
> So the users will have to register somewhere else the factories, how will
> they do it and where is a win, in terms of the simplification ? Putting
> some META-INF files is not worth considering IMHO, it is anti-dynamic.
> I agree people will not want mix 2 styles of RxJava in one piece of code
> but they should be able to select it from the code fast, once only, which
> is what the current proposal offers.
>
> Sergey
>
>
> On 13/01/17 23:19, Ondrej Mihályi wrote:
>
> Actually, I like the unwrap method more than the current proposal. It
> makes it explicit what I want to get when I write code. The current
> proposal is similar, but requires me to remember the name of the invoker on
> top of the rx interface I want to get.
>
> Compare:
>
>
> *Current proposal *
>
> CompletionStage<List<String>> cs = client.request()
> .rx(CompletionStageRxInvokerProvider.class)
> .get(new GenericType<List<String>>() {
> });
>
>
> *With unwrap
>
> *CompletionStage<List<String>> cs = client.request()
> .rx().unwrap(CompletionStage.class)
> .get(new GenericType<List<String>>() {
> });
>
> ... provided that a suitable provider for CompletionStage (or any other rx interface) is configured using SPI.
>
>
>
> to have an SPI that statically defines the return type of rx().
>
> I don't get this. How can an SPI define the return type? Markus, could you please give a code sample?
>
>
>
> Ondrej
>
> 2017-01-13 23:10 GMT+01:00 Markus KARG <markus_at_headcrashing.eu>:
>>
>> Ondrej,
>>
>>
>>
>> thank you for sharing your opinion.
>>
>>
>>
>> I am not against extensibility nor plugability, but against the
>> particular draft "rx(Client)".
>>
>>
>>
>> Months back I proposed to instead provide an SPI that switches the
>> outcome of rx() to a different time, this is much better, as within the
>> same program nobody ever wants to write things like "rx(TypeA.class);
>> rx(TypeB.class); rx(TypeC.class);" which the API not only allows, but
>> actually enforces.
>>
>>
>>
>> A much better way is to write "Client.rx().unwrap(Type.class)" (as you
>> propose and looks promising to me), or to have an SPI that statically
>> defines the return type of rx().
>>
>>
>>
>> I hope it is clear now what I do criticize and what not.
>>
>>
>>
>> -Markus
>>
>>
>>
>> *From:* Sergey Beryozkin [mailto:sberyozkin_at_talend.com] *Sent:* Freitag,
>> 13. Januar 2017 20:56 *To:* jsr370-experts_at_jax-rs-spec.java.net
>> *Subject:* Re: [jax-rs-spec users] Re: JAX-RS 2.1 - work schedule
>>
>>
>>
>> On 13/01/17 19:30, Ondrej Mihályi wrote:
>>
>> Hi Markus,
>>
>>
>>
>> I'm not a member of the EG, just a random JCP associate member. But I
>> wanted to have a word on this.
>>
>>
>>
>> I think that having an extendable API is really important for the future
>> of Java EE.
>>
>> +1, I'm not a Java EE expert but yes, for it to stay competitive, it has
>> to be more open
>>
>> It's always been the point to standardize what makes sense to
>> standardize, but allow implementations to extend the API. Many Java EE APIs
>> provide an "unwrap" method to retrieve provider specific API
>> (EntityManager.unwrap(), Validator.unwrap(), etc. )
>>
>>
>>
>> In what is having a version of rx() method that makes it possible to get
>> to a specific reactive API different to those unwrap() methods? Do you
>> think it is better to rename the rx() method to unwrap() method to be in
>> line with the other specifications?
>>
>>
>>
>> Ondrej
>>
>>
>>
>> 2017-01-13 20:02 GMT+01:00 Markus KARG <markus_at_headcrashing.eu>:
>>
>> I understand your arguments and I hope you understand mine too. As I am a
>> member of the JCP solely for the sake of creating industrial standars
>> (hence not of creating products), I have a slightly differen view of this.
>> I think it is critical that JAX-RS stays focused on long-term evolution
>> instead of extensibity of the current evolutionary step.
>>
>>
>>
>> The question now is, somebody has to decide what the final API shall be
>> like: (even slightly) more complex for each code line where it is getting
>> used but for the sake of being extendable - vs. - concise (and slightly
>> higher performant) - vs. - both variants. My vote is that we only support
>> CompletableStage in JAX-RS 2.1, and come up with additional
>> Java-10-native-RX-API support in JAX-RS 3.0 or 3.1, but not to keep the API
>> pluggable for any product that is not standardized by the JCP while ALL (!)
>> OTHER APIs of Java EE do not care the least about those products
>> (independent of their popularity).
>>
>>
>>
>> A second issue I can remember is that I asked whether it makes sense to
>> directly request a reactive client once (i. e. all further calls bear
>> CompletableStage), or whether we really want users to request a reactive
>> invocation for each and every invocation. I cannot remember that _that_
>> discussion ended with any concensus.
>>
>>
>>
>> But the question is, whether the Spec Lead decides that alone without
>> further discussion of the EG members, or whether the EG members have a real
>> say in that as in a democratic project. This is something Santiago has to
>> tell us. See, I don't want to bother, I actually just want to have clear
>> rules to follow. The JCP says, the EG defines the outcome. So we should at
>> least shortly discuss the pros and cons of different API variants as other
>> JSRs do, too, and not just nod through one single proposal for the sole
>> sake of getting done earlier.
>>
>>
>>
>> -Markus
>>
>>
>>
>>
>>
>> *From:* Sergey Beryozkin [mailto:sberyozkin_at_talend.com] *Sent:*
>> Donnerstag, 12. Januar 2017 21:04
>>
>> *To:* jsr370-experts_at_jax-rs-spec.java.net *Subject:* Re: [jax-rs-spec
>> users] JAX-RS 2.1 - work schedule
>>
>>
>>
>> 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 [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 [mailto:santiago.pericasgeerts
>> en_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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>