@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:
ThanksLooking forward for the PR ;-)17KB of dependencies for this are clearly fine.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.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
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
--
_______________________________________________ resteasy-dev mailing list resteasy-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/resteasy-dev