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
