has the code. Very
minimal: remove our own rx hooks, define a context provider service, and
make sure reactive contexts is loaded.
On 18/06/18 15:14, Stephane Epardaud wrote:
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.