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.

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