I think there’s value is doing a 1.9.1 patch release to support Spring users.
Anthony > On Aug 13, 2019, at 11:26 AM, Kirk Lund <kl...@apache.org> wrote: > > Udo, Thanks for the info! Sounds like we shouldn't bother with Geode 1.9.1 > then. If I'm misinterpreting what you wrote, let me know. > > On Tue, Aug 13, 2019 at 10:36 AM Udo Kohlmeyer <u...@apache.com> wrote: > >> The latest version of SBDG 1.2 is already in RC stage. Which means the >> dependent Geode version cannot be changed any more. Currently SBDG 1.2 >> is based on Geode 1.9. This will not change. Patch versions to 1.9 are >> supported, but not changes to 1.10 or later. >> >> THUS, >> >> Once SBDG 1.3 (Neuman) is released, it will be based on the latest GA of >> Geode, which at this point would be 1.10 or possibly 1.11 depending on >> release cycles. >> >> In addition... >> >> @Aaron, Whilst it would also be possible to override the underlying >> Geode version that SBDG uses, to a later version, I would just like to >> point out that all testing of SBDG will be against a named supported >> version of Geode / GemFire. Which means, if failures arise using SBDG / >> SDG with a non-supported version of Geode / GemFire would effectively be >> unsupported. (due diligence to confirm origin of failure will of course >> be applied) >> >> Hope this helps... >> >> --Udo >> >> On 8/13/19 10:03 AM, Aaron Lindsey wrote: >>> Assuming Geode 1.10 is released with the three logging fixes in Kirk’s >> message, can the next GA release of Spring Boot Data Geode consume 1.10 >> instead of 1.9? Also, when would SBDG need this patch release by (whether >> we do a 1.9.1 release or 1.10 release)? >>> >>> - Aaron >>> >>>> On Aug 13, 2019, at 9:31 AM, Bruce Schuchardt <bschucha...@pivotal.io> >> wrote: >>>> >>>> If we release a 1.9.1 I'd like to include the SSL/NIO fix. Cluster SSL >> communications with conserve-sockets=false is currently broken in 1.9. >>>> >>>> On 8/13/19 9:25 AM, Kirk Lund wrote: >>>>> I'd like to discuss if and how we can release Geode 1.9.1 with logging >>>>> improvements. This is primarily to provide a patch release for Spring >> Data >>>>> Geode and Spring Boot to ensure a smoother User experience out-of-the >> box. >>>>> They have very near-future releases that need this as soon as possible. >>>>> >>>>> The specific tickets and commits that would be back-ported are: >>>>> >>>>> *1. GEODE-7058 Log4j-core dependency should be optional in geode-core* >>>>> >>>>> commit 413800bc16d05df689a2af5c30797f180aad6088 >>>>> Author: Kirk Lund <kl...@apache.org> >>>>> Date: Wed Aug 7 14:33:21 2019 -0700 >>>>> >>>>> GEODE-7058: Mark log4j-core optional in geode-core >>>>> >>>>> Note: this change requires all commits from GEODE-2644 and >> GEODE-6122. >>>>> >>>>> *2. GEODE-7050 Log4jAgent should avoid casting non-log4j loggers* >>>>> >>>>> commit e5c9c420f462149fd062847904e3435fbe99afb4 >>>>> Author: Kirk Lund <kl...@apache.org> >>>>> Date: Thu Aug 8 18:17:32 2019 -0700 >>>>> >>>>> GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider >> (#3892) >>>>> >>>>> This change prevents Geode from using Log4jAgent if Log4j Core is >>>>> present but not using Log4jProvider. >>>>> >>>>> For example, Log4j uses SLF4JProvider when log4j-to-slf4j is in >> the >>>>> classpath. >>>>> >>>>> By disabling Log4jAgent when other Log4j Providers are in use, >> this >>>>> prevents problems such as ClassCastExceptions when attemping to >> cast >>>>> loggers from org.apache.logging.slf4j.SLF4JLogger to >>>>> org.apache.logging.log4j.core.Logger to get the LoggerConfig or >>>>> LoggerContext. >>>>> >>>>> Co-Authored-By: Aaron Lindsey <alind...@pivotal.io> >>>>> >>>>> *3. GEODE-6959 NPE if AlertAppender is not defined* >>>>> >>>>> commit dd15fec1f2ecbc3bc0cdfc42072252c379e0bb89 >>>>> Author: Kirk Lund <kl...@apache.org> >>>>> Date: Thu Aug 8 14:59:44 2019 -0700 >>>>> >>>>> GEODE-6959: Prevent NPE in GMSMembershipManager for null >> AlertAppender >>>>> (#3899) >>>>> >>>>> If a custom log4j2.xml is used without specifying the Geode >>>>> AlertAppender, >>>>> GMSMembershipManager may throw a NullPointerException when >> invoking >>>>> AlertAppender.getInstance().stopSession() during a >> forceDisconnect. This >>>>> change prevents the NullPointerException allowing forceDisconnect >> to >>>>> finish. >>>>> >>>>> Users using Spring Boot with Logback are more likely to hit this >> bug. >>>>> >>>>> Co-authored-by: Mark Hanson mhan...@pivotal.io >>>>> >>
