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 > >>> >
