geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Blum <jb...@pivotal.io>
Subject Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Date Thu, 05 Dec 2019 00:15:17 GMT
See comment
<https://issues.apache.org/jira/browse/GEODE-7531?focusedCommentId=16988282&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16988282>
[1]
on ticket, GEODE-7531 <https://issues.apache.org/jira/browse/GEODE-7531>
 [2].

Quite frankly the reasons STDG (or dependent projects downstream like SDG,
SBDG, SSDG) are doing what it is (they are) doing is irrelevant to point
articulated in the description of GEODE-753.

[1]
https://issues.apache.org/jira/browse/GEODE-7531?focusedCommentId=16988282&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16988282
[2] https://issues.apache.org/jira/browse/GEODE-7531

On Wed, Dec 4, 2019 at 4:06 PM Dan Smith <dsmith@pivotal.io> wrote:

> On Wed, Dec 4, 2019 at 2:11 PM John Blum <jblum@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
>


-- 
-John
Spring Data Team

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message