On Wed, Dec 4, 2019 at 2:11 PM John Blum <jb...@pivotal.io> wrote: > This is not a test failure in SDG. SDG builds fine with Apache Geode 1.11 > (and all tests pass), as I indicated above in my origin +0 vote. > > This is a definitive problem for SBDG when using STDG to mock Apache Geode > resources/objects, which is caused by GEODE-7531. >
Hmm, looks like STDG is also using an internal API to inject a mock into the PoolManager singleton: https://github.com/spring-projects/spring-test-data-geode/blob/9a091376528cd79c978bc5b3019d30256fcf3fd5/spring-data-geode-test/src/main/java/org/springframework/data/gemfire/tests/mock/GemFireMockObjectsSupport.java#L1750 Maybe it would be better to fix that? I don't think injecting anything into Geode singletons is a good approach - it will likely lead to mysterious errors in future tests. And using internal APIs tends to result in breakage while upgrading, as evidenced here. A more complete fix to Geode might be deprecate the static PoolManager entirely and move the pool management functionality to ClientCache. That might make it easier for you to mock the whole system? In the short term perhaps SDG, STDG, etc. can wrap the PoolManager in something that can have a mock injected into it, without using internal APIs? -Dan
