Thanks, Udo. +1 for doing a 1.9.1 patch release, assuming there is enough time for SBDG to include it in their 1.2.x line.
- Aaron > On Aug 13, 2019, at 12:38 PM, Udo Kohlmeyer <u...@apache.com> wrote: > > No, 1.9.1 IS something we require. SBDG 1.2 CAN use 1.9.1, we'd have to wait > for SBDG 1.3 to use 1.10 or 1.11 > > SBDG 1.3 is still a few months off, so maybe getting critical fixes in patch > versions is required. > > On 8/13/19 11:26 AM, Kirk Lund 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 >>>>>>
