Hi All, It does not look like we have an assignee for GEODE-7531. Any takers?
Thanks, Mark > On Dec 4, 2019, at 2:35 PM, Mark Hanson <mhan...@pivotal.io> wrote: > > So, outstanding issues that I see right now are > > GEODE-7531 > GEODE-7537 > GEODE-7538 > > Thanks, > Mark > >> On 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. >> >> Either way, the design/code changes made in GEODE-6759 were poor and should >> be fixed regardless which GEODE-7531 describes. >> >> -j >> >> >> On Wed, Dec 4, 2019 at 2:04 PM Dan Smith <dsm...@pivotal.io> wrote: >> >>> On Wed, Dec 4, 2019 at 11:16 AM John Blum <jb...@pivotal.io> wrote: >>> >>>> I am changing my vote to -1! >>>> >>>> I have filed GEODE-7531 < >>> https://issues.apache.org/jira/browse/GEODE-7531> >>>> [1], >>>> which is a serious blocking issue for all things *Spring* for Apache >>>> Geode. This issue alone is currently preventing me from upgrading >>> *Spring >>>> Boot for Apache Geode* (SBDG) to Apache Geode 1.10, which I plan to do in >>>> SBDG 1.3, which is based on *Spring Data for Apache Geode* (SDG) >>>> Neumann/2.3, which is currently already pulling in Apache Geode 1.10, >>> soon >>>> to be upgraded to 1.11 once this issue is resolved and 1.11 is available. >>>> >>> >>> >>> I commented on the above JIRA. While we definitely don't want to break >>> spring data geode, it looks like maybe the issue is just with one unit test >>> in Spring Data Geode using an internal geode API to inject something into a >>> singleton? If that's the case, I think it would be better to fix that one >>> test in SDG. >>> >>> -Dan >>> >> >> >> -- >> -John >> Spring Data Team >
