Skip to content
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

Refactor ContinuousQueryListenerContainer to use PoolResolver [DATAGEODE-280] #325

spring-projects-issues opened this issue Dec 5, 2019 · 1 comment
in: api in: core type: enhancement


Copy link

spring-projects-issues commented Dec 5, 2019

Dan Smith opened DATAGEODE-280 and commented

This test uses geode's internal PoolManagerImpl class to install a Pool into Geode's singleton list of available Pools.

This is problematic for two reasons:

  1. PoolManagerImpl is an internal class in Geode, it may change or be removed at any time.
  2. This installing a mock object into a Geode singleton. This may cause strange behavior in future tests that are running in the same JVM.

In this case, I think this use of PoolManagerImpl looks like it should be easy to remove. If ContiniousQueryListenerContainer provided a way to inject an object to be used to look up Pools, rather than directly depending on the static PoolManager.find method, the test could avoid having to change the real Geode singleton

Affects: 2.1.14 (Lovelace SR14), 2.2.3 (Moore SR3)

Reference URL:

Backported to: 2.2.4 (Moore SR4)

Copy link

spring-projects-issues commented Dec 5, 2019

John Blum commented

This will change ContinuousQueryListenerContainer from depending (directly) on the Apache Geode PoolManager class in its implementation at all.


It will also make the Pool resolution logic easily pluggable (e.g. for mocking)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: api in: core type: enhancement
None yet

No branches or pull requests

2 participants