-
Notifications
You must be signed in to change notification settings - Fork 7.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make RxJavaPlugins.reset() public #2297
Comments
I'm open to making it public. Do you want to submit the PR to make the change? There are 2 reasons it is not public:
Of course, if someone wants to do that bad thing we can't prevent it anyways, since all someone has to do is put a class inside the same package and invoke /cc @akarnokd @mattrjacobs @abersnaze for your thoughts on this |
Some good points. I definitely agree with "as private as possible" by default. After looking into it some more, I see that my use case would not precisely be served by this -- even if I could re-register a different hook, the For now I am solving my testing issue by injecting a So, rambling aside -- making |
Why don't you use operators which let you parametrize the scheduler and not rely on the defaults? For the other hooks, you could set up a level of indirection, i.e., you register your own hook which then does allow setting/removing further hooks at will. You can even create it such a way that multiple hooks can work at the same time, but you have to implement a separate Observable-Observer and make careful decisions when these hooks return some value instead of just consuming. |
As a work around for this what I have done by now is defining a RxJavaTestPlugins class on src/test/java/rx/plugins
And then invoke If your run it on the |
I very much would like something like this, too. I do something similar to what you have but as a JUnit rule so it can be used as: @Rule public final RxJavaPluginsResetRule pluginsReset = new RxJavaPluginsResetRule(); and it calls |
FYI RxAndroid shipped with a |
@JakeWharton Is there really a point of doing .reset() in your Rule? To me it doesn't seem to have the expected effect. Any subsequent call to Schedulers.* will still return the same original Scheduler even after calling .reset(). Since the hooks are only called once when the Schedulers instance is created. I can't seem to find a valid use case for using RxJavaPlugins to register test schedulers in unit tests really. Maybe it was never intended for that anyway. |
Here's an example of how you can accidently misuse TestScheduler to break unrelated tests. |
Actually, using a singleton TestScheduler wrapper we can more easily identify when we accidently initialize Schedulers before our hook is called (instead of just getting weird behavior in the test): However, that would require all unit tests that happen to execute any code that would initialize Schedulers to first initialize our TestSchedulerProxy (which registers the hook). And possibly also advance / trigger the test scheduler I guess. |
I ran into this exact problem and it was frustrating. I ended up creating the following TestWatcher, which is specific to verifying that there are no leaking subscriptions, but I suppose could be used more generally.
then in the test you need to add the following:
or in a Test Suite class you could do this if you want to use the rule on all tests.
|
I also think making The closes I got was from the constructor of a custom test Runner but this only works for the first test case, the rest would throw the exception above. So the two option I have is catch the |
@ivacf Not sure if you are referring to my previous comment, but it's very important that you add:
to whatever class groups all you're tests. If you don't have a suite that groups tests, then it's possible this might have to be done before each test. Anyway, this was tricky and frustrating for the reasons you already mentioned. |
👍 |
1) Because RxJavaPlugins is protected does not expose `reset()`, a wrapper had to be introduced. More details can be found here: ReactiveX/RxJava#2297 2) The implementation (and testing) strategy was followed per HystrixConcurrencyStrategy implementation.
Hi! @benjchristensen @akarnokd @mattrjacobs @abersnaze - any news on this? It doesn't seem like a big change and would certainly be helpful in Spring Cloud Sleuth's intergration with RxJava. |
1) Because RxJavaPlugins is protected does not expose `reset()`, a wrapper had to be introduced. More details can be found here: ReactiveX/RxJava#2297 2) The implementation (and testing) strategy was followed per HystrixConcurrencyStrategy implementation.
I don't use the plugin API so can't tell if its worth it or what consequences it holds. PR welcome. |
1) Because RxJavaPlugins is protected does not expose `reset()`, a wrapper had to be introduced. More details can be found here: ReactiveX/RxJava#2297 2) The implementation (and testing) strategy was followed per HystrixConcurrencyStrategy implementation.
Discussions found here: ReactiveX#2297
1) Because RxJavaPlugins is protected does not expose `reset()`, a wrapper had to be introduced. More details can be found here: ReactiveX/RxJava#2297 2) The implementation (and testing) strategy was followed per HystrixConcurrencyStrategy implementation. 3) Adding integration test cases
Discussions found here: ReactiveX#2297 Adding @experimental tag because exposing reset() could be dangerous
Discussions found here: ReactiveX#2297 Adding @experimental tag because exposing reset() could be dangerous Adding javadocs for `reset()` API. Explicitly mentioning how caution is advised when using `reset()` API. Also mentioning links to detailed discussions on github issue.
Discussions found here: #2297 Adding @experimental tag because exposing reset() could be dangerous Adding javadocs for `reset()` API. Explicitly mentioning how caution is advised when using `reset()` API. Also mentioning links to detailed discussions on github issue.
Closing via #3820 |
I'm getting problem when I use:
How can it be possible? |
Not sure if its related to this issue, but just wanted to say that RxJava2 changed a few things about how to override schedulers. I found another way outlined here: http://stackoverflow.com/a/43320828/3870025 |
This is the latest in the 1.x rxJava branch, now EOL'ed. The primary driver for updating is the fix for this issue: ReactiveX/RxJava#2297 (comment)
This is the latest in the 1.x rxJava branch, now EOL'ed. The primary driver for updating is the fix for this issue: ReactiveX/RxJava#2297 (comment)
Let me preface this by saying the RxJava library has made my life easier in just the short time I've been using it. However, there's one jagged edge that bit me today.
I'm attempting to use the
RxJavaPlugins
class to override the default schedulers viaregisterSchedulersHook
. However, I want to only override the defaults for a single JUnit test. Ideally, I would callRxJavaPlugins.getInstance().reset()
in my@After
method...but I can't, because it is package private.I could get at it via reflection, but it'd be easier if it was public -- unless there is a) a very good reason it is not or b) there is an obvious alternative I am missing (always a possibility!)
The text was updated successfully, but these errors were encountered: