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(a)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
listresteasy-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/resteasy-dev
_______________________________________________
resteasy-dev mailing list
resteasy-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/resteasy-dev