9:14 a.m.
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.
10:13 a.m.
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> 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
--
Alessio Soldano
Associate Manager
Red Hat
<https://www.redhat.com>
<https://red.ht/sig>
10:14 a.m.
https://github.com/resteasy/Resteasy/pull/1572 has the code. Very
minimal: remove our own rx hooks, define a context provider service, and
make sure reactive contexts is loaded.
On 18/06/18 15:14, Stephane Epardaud wrote:
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.
10: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>
7:27 p.m.
Very nice!! Much better. Hats off to Professeur Fromage!!
On 06/18/2018 10:21 AM, Stephane Epardaud wrote:
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>
>
_______________________________________________
resteasy-dev mailing list
resteasy-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/resteasy-dev
--
My company's smarter than your company (unless you work for Red Hat)
10:49 a.m.
Hi,
Ron, Alessio, I've added some questions to
https://github.com/resteasy/Resteasy/pull/1572, could you take a look
please?
Thanks, cheers.
10:39 a.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
3:18 a.m.
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
--
Alessio Soldano
Associate Manager
Red Hat
<https://www.redhat.com>
<https://red.ht/sig>
3:26 a.m.
On 14/09/18 09:18, Alessio Soldano wrote:
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,
That's what I was told, essentially, and that's a hill I'm not willing
to die on, so I just followed their plan.
I'm fine with your proposal.
OK thanks, good to know.
9:58 a.m.
So I finally have a snapshot version of smallrye-concurrency that is
pushed to the nexus oss snapshots, and the mpconcurrency snapshot to
eclipse maven snapshots too, which means I can finally open a PR on
resteasy to try out the smallrye-concurrency variant on resteasy's CI.
I will open the PR tomorrow, but it's not for merging: it's only for
testing on the CI because there was a classloader-related bug I fixed in
reactivecontexts that I want to make sure does not cause any issue in
smallrye-concurrency, and I was never able reproduce it outside of the
CI. So when you see the PR, can you please send it on its way to the CI
and not merge it ?
Thanks!
12:05 p.m.
Sure, it will be automatically tested. To signal that the PR is not meant
to be merged, feel free to use our label "DoNotMerge".
Thanks
On Wed, Oct 10, 2018 at 3:59 PM Stephane Epardaud <stef(a)epardaud.fr> wrote:
So I finally have a snapshot version of smallrye-concurrency that is
pushed to the nexus oss snapshots, and the mpconcurrency snapshot to
eclipse maven snapshots too, which means I can finally open a PR on
resteasy to try out the smallrye-concurrency variant on resteasy's CI.
I will open the PR tomorrow, but it's not for merging: it's only for
testing on the CI because there was a classloader-related bug I fixed in
reactivecontexts that I want to make sure does not cause any issue in
smallrye-concurrency, and I was never able reproduce it outside of the
CI. So when you see the PR, can you please send it on its way to the CI
and not merge it ?
Thanks!
_______________________________________________
resteasy-dev mailing list
resteasy-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/resteasy-dev
--
Alessio Soldano
Associate Manager
Red Hat
<https://www.redhat.com>
<https://red.ht/sig>
4:33 a.m.
I actually can't set labels :(
On 10/10/18 18:05, Alessio Soldano wrote:
Sure, it will be automatically tested. To signal that the PR is not
meant to be merged, feel free to use our label "DoNotMerge".
Thanks
On Wed, Oct 10, 2018 at 3:59 PM Stephane Epardaud <stef(a)epardaud.fr
<mailto:stef@epardaud.fr>> wrote:
So I finally have a snapshot version of smallrye-concurrency that is
pushed to the nexus oss snapshots, and the mpconcurrency snapshot to
eclipse maven snapshots too, which means I can finally open a PR on
resteasy to try out the smallrye-concurrency variant on resteasy's CI.
I will open the PR tomorrow, but it's not for merging: it's only for
testing on the CI because there was a classloader-related bug I
fixed in
reactivecontexts that I want to make sure does not cause any issue in
smallrye-concurrency, and I was never able reproduce it outside of
the
CI. So when you see the PR, can you please send it on its way to
the CI
and not merge it ?
Thanks!
_______________________________________________
resteasy-dev mailing list
resteasy-dev(a)lists.jboss.org <mailto:resteasy-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/resteasy-dev
--
Alessio Soldano
Associate Manager
Red Hat
<https://www.redhat.com>
<https://red.ht/sig>
10:14 a.m.
ah, so it's only for committers. Anyway, I've set it.
Thanks
On Thu, Oct 11, 2018 at 10:33 AM Stephane Epardaud <stef(a)epardaud.fr> wrote:
I actually can't set labels :(
On 10/10/18 18:05, Alessio Soldano wrote:
Sure, it will be automatically tested. To signal that the PR is not meant
to be merged, feel free to use our label "DoNotMerge".
Thanks
On Wed, Oct 10, 2018 at 3:59 PM Stephane Epardaud <stef(a)epardaud.fr>
wrote:
> So I finally have a snapshot version of smallrye-concurrency that is
> pushed to the nexus oss snapshots, and the mpconcurrency snapshot to
> eclipse maven snapshots too, which means I can finally open a PR on
> resteasy to try out the smallrye-concurrency variant on resteasy's CI.
>
> I will open the PR tomorrow, but it's not for merging: it's only for
> testing on the CI because there was a classloader-related bug I fixed in
> reactivecontexts that I want to make sure does not cause any issue in
> smallrye-concurrency, and I was never able reproduce it outside of the
> CI. So when you see the PR, can you please send it on its way to the CI
> and not merge it ?
>
> Thanks!
> _______________________________________________
> resteasy-dev mailing list
> resteasy-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/resteasy-dev
>
--
Alessio Soldano
Associate Manager
Red Hat
<https://www.redhat.com>
<https://red.ht/sig>
_______________________________________________
resteasy-dev mailing list
resteasy-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/resteasy-dev
--
Alessio Soldano
Associate Manager
Red Hat
<https://www.redhat.com>
<https://red.ht/sig>
2022
days inactive
2137
days old
12 comments
3 participants
participants (3)
-
Alessio Soldano -
Ron Sigal -
Stephane Epardaud