This would then imply a SBDG 1.2.1 to include Geode 1.9.1.

On Tue, Aug 13, 2019 at 11:55 AM Anthony Baker <aba...@pivotal.io> wrote:

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

Reply via email to