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/89badabb88b4d98e7f8d06f0ae0330ca21227bfe
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@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


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




--

Alessio Soldano

Associate Manager

Red Hat