Though may be it is a not a big deal, providing the factories as the input parameters, will be a matter of changing a package and name of the provider if someone decide to switch.
I like the rx(Observable.class) a bit more, but wonder a bit how well it work in OSGI..., anyway, some initial thoughts
________________________________
From: Sergey Beryozkin <sberyozkin_at_talend.com>
Sent: 16 January 2017 10:21:38
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: How to register RX providers
Hi All, thought I'd start a new thread in order to avoid overloading,
On 15/01/2017 17:20, Sergey Beryozkin wrote:
IMHO rx() needs to remain in order to get the default, this is as simple as it can get. Doing more than rx() in order to get CompletionStage would be bad.
But I'm warming to something similar to what you are suggesting. .unwrap() is redundant IMHO.
either rx() for the default
or, example,
RxInvoker<Observable> rxInvoker = rx(Observable.class)
The reason it works better than the prototype suggested by Pavel is that this code is *portable*.
Clearly, in most cases, it won't be the users who will create RxInvoker<Observable>, etc but Jersey, CXF, RestEasy will have dedicated modules with META-INF linking, in this case, Observable to a specific RxInvoker. This will be documented and users willing to work with non-default rx() will add a given module to the classpath...
Ideally, RxInvoker<Observable> is not created by Jersey nor CXF nor RestEasy, but by 3rd party library, which works on ALL JAX-RS implementations. Ideally RxJava itself could provide RxInvokerFactory (or however that will end up named).
It won't happen, ideally may be, but it won't - why would one host such a library and then maintain and release it ? At least the JAX-RS 2.1 projects will do and it will guarantee the users these libraries are in good shape. Someone can decide to do such a library but would you recommend Jersey users wait till it happens ?
That would allow the real portability, since you won't need to care about which implementation is underneath and which features does it provide. It will just work everywhere.
I don't understand. In your proposal we have
.rx(CompletionStageRxInvokerProvider.class)
Users will want to use something like that, ex, after JAX-RS 2.1 final is out, (for RxJava for ex), immediately. So are you saying they will have to wait for some kind of a market place to appear where these libraries will be made available but would be implementers ?
Even it it will happen, JAX-RS 2.1 projects will def ship their own implementations, CXF will def do it. And here is my point,
.rx(CompletionStageRxInvokerProvider.class)
will introduce a CXF/etc package into the code.
.rx(CompletionStage.class)
will work with whatever library the users will choose, from Jersey, some 3rd party library, etc
Thanks, Sergey
Thanks and regards,
Pavel
Sergey
On 14/01/17 14:28, Markus KARG wrote:
Sounds good for me, but actually I think it would be even simpler if we name it "unwrap()", and do not fill in any parameters. As I said, I think applications will typically use only one technology at the time. So "unwrap()" simply can check if there is a @Provider registered having a method with the same parameters as your proposed "conver()", we finally have the requested plugability, no additonal complexity, follow existing JAX-RS patterns, and get rid of repeating lots of "rx(Class)". :-)
-Markus
From: Ondrej Mihályi [<mailto:ondrej.mihalyi_at_gmail.com>mailto:ondrej.mihalyi_at_gmail.com]
Sent: Samstag, 14. Januar 2017 12:54
To: jsr370-experts_at_jax-rs-spec.java.net<mailto:jsr370-experts_at_jax-rs-spec.java.net>
Subject: Suggestion to refactor rx invoker API
I was thinking about an alternative to current rx API, to simplify it in context of supporting extensibility.
My idea is to modify the CompletionStageRxInvoker, so that it returns an extension to CompletionStage, which would contain additional method to convert the interface to any other reactive interface:
public interface RxCompletionStage<T> extends CompletionStage<T> {
<NEW> NEW convert(Function<CompletionStage<T>, NEW> converter);
}
With this, we would move all the complexity to this new interface, which still can be used as a usual CompletionStage, but with the additional convert method, it provides an extension point to other interfaces. And it's based on standard CompletionStage, therefore we don't need additional rx invokers.
We could remove RxInvokerProvider, the 2 rx() methods from the Builder, which accept RxInvokerProvider, and even remove the RxInvoker interface, as CompletionStageRxInvoker would be the only required implementation.
Here is an example of what I mean, with RxJava2 as an example:
client.request().rx().get(). // we get the RxCompletionStage here, which extends CompletionStage
.convert(this::flowableFromStage) // accepts a function that converts the CompletionStage to another interface
.subscribe(s -> testResult = s, Throwable::printStackTrace);
An example of a working code here<
https://github.com/OndrejM-demonstrations/JavaEEReactive/blob/rxjava/src/test/java/reactivejavaee/CompletionStageRxJavaTest.java#L120> (although not using JAX-RS, just wrapping a method that returns a CompletionStage).
Ondrej