Hi Stephane,
I've read you a bit talking about this on the other mailing list. While I'm not super convinced that anything that happen to touch MP have necessarily to live in smallrye, I'm fine with your proposal.

Thanks


On Thu, Sep 13, 2018 at 4:39 PM, Stephane Epardaud <stef@epardaud.fr> wrote:

Hi,

Fun times. It appears MP has taken hold of this problem and has come up with MP-Concurrency (https://github.com/eclipse/microprofile-concurrency) which I'm participating in, in order to make sure our use-cases are covered, because I don't think we can afford to have two implementations that solve the same context propagation issue, and MP doesn't want ReactiveContexts. So I've started https://github.com/smallrye/smallrye-concurrency which builds on top of the spec to validate that it's sane, and to extend it with our use-cases that haven't made it in the spec.

Next I will try to see if I can change RESTEasy to use smallrye-concurrency insted of ReactiveContexts, if you guys agree on replacing this dependency. TBH I think we'll be forced by the MP spec's existence: we can't just ignore it and do our own thing. This implementation has only a single dependency which is the spec (which in turn has no dependency). It's still a tiny implementation, even if it's a tad bigger due to having extra use-cases.

Let me know if you agree. Cheers.


On 18/06/18 15:14, Stephane Epardaud wrote:

Hi,

At the moment, the resteasy-rxjava and resteasy-rxjava2 modules register hooks into the rxjava and rxjava2 plugin/hook system, in order to propagate the RESTEasy context (thread-local) into all phases of rxjava single/flowable/etc, which can otherwise be scheduled on any scheduler/thread and so would lose the RESTEasy context.

RxJava being what it is, you can only register a single plugin/hook globally, so if RESTEasy defines it, nobody else can. That's problematic, because CDI also requires context propagation, and so does Redpipe (to name just the two examples I am using ATM), so I created a library called Reactive Contexts which decouples libraries that have a context to propagate (RESTEasy, CDI, Redpipe, etc…) and libraries that provide context propagation (RxJava1, 2, etc…).

https://reactiverse.io/reactive-contexts

That library is super small (4k core, 13k propagator for rxjava). I'd like to remove the custom context propagation in the resteasy-rxjava/rxjava2 and make those modules depend on a new resteasy-reactive-context which would depend on reactive-contexts-core to provide a context provider for RESTEasy.

This way, I can also make CDI and Redpipe provide such a module and all those contexts will be propagated for rxjava for all users :)

WDYT? Do you agree on that extra dependency ? It's only for the rxjava modules, not the core.




_______________________________________________
resteasy-dev mailing list
resteasy-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/resteasy-dev


_______________________________________________
resteasy-dev mailing list
resteasy-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/resteasy-dev




--

Alessio Soldano

Associate Manager

Red Hat