Refactor ContinuousQueryListenerContainer to use PoolResolver [DATAGEODE-280]

[spring-projects-issues]

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.

spring-data-geode/spring-data-geode/src/test/java/org/springframework/data/gemfire/listener/ContinuousQueryListenerContainerUnitTests.java

Line 114 in 896d885

PoolManagerImpl.getPMI().register(mockPool);

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: https://jira.spring.io/browse/DATAGEODE-281

Backported to: 2.2.4 (Moore SR4)

[spring-projects-issues]

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)