4:39 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/resteasy-dev