9:21 a.m.
Oh yeah, funny indeed. What sucks is that there's no plugin/hook for
automatic context propagation for CompletionStage, but yes, we could
mention in the docs you pointed to that for rxjava1/2 this actually
works and is automatic. We could also point out that if you import the
resteasy-reactive-context module, you can rewrite the example with:
@GET
@Path("test")
@Produces("text/plain")
public CompletionStage<String> text(@Context HttpRequest request) {
System.out.println("request (inline): " + request);
System.out.println("application (inline): " +
ResteasyProviderFactory.getContextData(Application.class));
CompletableFuture<String> cs = new CompletableFuture<>();
ExecutorService executor = Executors.newSingleThreadExecutor();
Object[] contexts = Context.capture();
executor.submit(
new Runnable() {
public void run() {
Object[] oldContexts = Context.install(contexts);
try {
System.out.println("request (async): " + request);
System.out.println("application (async): " +
ResteasyProviderFactory.getContextData(Application.class));
cs.complete("hello");
} catch (Exception e) {
e.printStackTrace();
} finally {
Context.restore(oldContexts);
}
}
});
return cs;
}
Note that this gets you the resteasy context but also CDI and any other
reactive context provider that is in the classpath.
And in fact I think I should add wrappers that do this automatically for
Runnable and CompletionStage in reactive-contexts-core, now that I look
at this.
On 18/06/18 16:13, Alessio Soldano wrote:
Hi Stephane,
funnily enough, the last commit on resteasy master is related to the
issue you're mentioning:
https://github.com/resteasy/Resteasy/commit/89badabb88b4d98e7f8d06f0ae033...
So, yes, I think a solution for this problem will always be better
than only telling users to be aware of the problem, which is what we
were going to do.
17KB of dependencies for this are clearly fine.
Looking forward for the PR ;-)
Thanks
On Mon, Jun 18, 2018 at 3:14 PM, Stephane Epardaud <stef(a)epardaud.fr
<mailto:stef@epardaud.fr>> 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
<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 <mailto:resteasy-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/resteasy-dev
<https://lists.jboss.org/mailman/listinfo/resteasy-dev>
--
Alessio Soldano
Associate Manager
Red Hat
<https://www.redhat.com>
<https://red.ht/sig>