+1 Yes! SBDG needs the Apache Geode 1.9.1 release with the Logging changes if you want to see Apache Geode on *Spring Initializer*. The Logging issues are impeding the presence of Apache Geode on *Initializer* at start.spring.io.
On Wed, Aug 28, 2019 at 4:48 PM Anthony Baker <aba...@pivotal.io> wrote: > I think it makes sense to do a 1.9.1 release for the same reasons that we > proposed it originally. It looks like we all missed the VOTE thread (it > was on my // todo list). In the past when we’ve had insufficient votes, > we've extended the deadline and asked for help reviewing the release. > > Anthony > > > > On Aug 28, 2019, at 1:38 PM, Owen Nichols <onich...@pivotal.io> wrote: > > > > The VOTE for 1.9.1.RC1 failed due to lack of quorum, so re-opening this > thread to continue the discussion. > > > > Is there still a need for a 1.9 patch release (especially given that > 1.10.0.RC1 is expected later this week)? > > > > If so, perhaps we should back up a step or two and first: > > 1) come to rough consensus that 1.9.1 is still desired (and what should > be in it) > > 2) ensure that we have Geode PMC support for this release > > 3) go through the formal process of voting each cherry-pick in the patch > release > > > > This could result in a recommendation to re-vote on RC1, a > recommendation to produce a new RC2, a recommendation to pull the plug (or > no recommendation). > > > > As a failsafe, I hereby invoke lazy consensus: In the event that no > explicit decision to move forward with 1.9.1 is reached by 3pm PDT Wed Sep > 4, I will dismantle the current 1.9.1 branch, pipeline and nexus staging > repo and remove 1.9.1 from the release notes wiki. > > > > -Owen > > > > > >> On Aug 18, 2019, at 7:52 AM, Anthony Baker <aba...@pivotal.io> wrote: > >> > >> Yep. Get a release manager, identify and cherry pick all the changes, > then do the release. > >> > >> Anthony > >> > >>> On Aug 16, 2019, at 4:21 PM, Kirk Lund <kl...@apache.org> wrote: > >>> > >>> Does anyone know what the next step is? Do we need a release manager to > >>> proceed? > >>> > >>>> On Tue, Aug 13, 2019 at 1:57 PM John Blum <jb...@pivotal.io> wrote: > >>>> > >>>> Sorry, corrections below... > >>>> > >>>>> On Tue, Aug 13, 2019 at 1:54 PM John Blum <jb...@pivotal.io> wrote: > >>>>> > >>>>> Stated slightly a different way... > >>>>> > >>>>> If *SBDG 1.2 *were to be (re)based on *Apache Geode 1.10* directly, > then > >>>>> it would *defy* the dependency on Apache Geode pulled in by SDG > Moore/2.2 > >>>>> (which is and can only be Geode 1.9 *at this point*) for which SBDG > is > >>>>> also based, along with Spring Boot 2.2, which pulls in SD Moore/2.2 > and > >>>>> therefore Geode 1.9, *indirectly (i.e. transitively)*, as well. As > such, > >>>>> the stars would not align and it would cause issues (or unexpected > >>>>> surprises, possibly conflicts) for users of Spring Boot when also > using > >>>>> SBDG. *With**out* SBDG, users of Spring Boot would get Geode 1.9 > due to > >>>>> the SD Moore/2.2 dependency, but with SBDG on the classpath, it would > >>>>> suddenly (possibly) change the Geode version to 1.10. That is > >>>> definitively > >>>>> bad. > >>>>> > >>>>> Therefore, SBDG 1.2 based on Boot 2.2, Data 2.2 will get Geode 1.9. > >>>>> > >>>>> SBDG 1.3 will be based on Boot 2.3 (not available), Data 2.3 (not > >>>>> available) which will pull in the latest version of Geode at that > time > >>>>> (e.g. 1.10, maybe 1.11) and continue to be upgraded until 2.3 > reaches RC > >>>>> status. > >>>>> > >>>>> Cheers, > >>>>> John > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> On Tue, Aug 13, 2019 at 1:45 PM John Blum <jb...@pivotal.io> wrote: > >>>>>> > >>>>>> For clarification... > >>>>>> > >>>>>> 1. SBDG 1.1 is the "*current*" development line (on > >>>>>> < > >>>> > https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17 > >>>>> > >>>>>> master > >>>>>> < > >>>> > https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17 > > > >>>> [1]); > >>>>>> SBDG 1.2 is *not* yet in development. > >>>>>> 2. SBDG 1.1 is at RC1 > >>>>>> <https://github.com/spring-projects/spring-boot-data-geode/releases > > > >>>> [2]. > >>>>>> 3. SBDG 1.1 is based on Spring Boot 2.1 > >>>>>> < > >>>> > https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L8 > > > >>>> [3] > >>>>>> and Spring Data (Geode) Lovelace > >>>>>> < > >>>> > https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L12 > > > >>>> [4] > >>>>>> (or SDG 2.1 > >>>>>> < > >>>> > https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L10 > > > >>>> [5]); > >>>>>> This is not arbitrary because all the stars (bits, transitive > dependency > >>>>>> versions) must "align" as defined by what Spring Boot 2.1 declares, > and > >>>>>> Spring Boot 2.1 is based on > >>>>>> < > >>>> > https://github.com/spring-projects/spring-boot/blob/v2.1.7.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L169 > > > >>>> [6] > >>>>>> Spring Data Lovelace/2.1. > >>>>>> 4. Spring Data Geode (SDG) Lovelace/2.1 is based on > >>>>>> < > >>>> > https://github.com/spring-projects/spring-data-geode/blob/2.1.10.RELEASE/pom.xml#L25 > > > >>>> [7] > >>>>>> Apache Geode 1.6. > >>>>>> 5. All SDG Lovelace/2.1.x versions will always be based on the > latest > >>>>>> Apache Geode 1.6.x anything (currently, 1.6.0) until the rest of > time. > >>>>>> This ship has sailed. > >>>>>> > >>>>>> ~~~~ > >>>>>> > >>>>>> 6. SBDG 1.2, when it reaches development (soon),will be based on > Spring > >>>>>> Boot 2.2 > >>>>>> < > >>>> > https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L8 > > > >>>> [8], > >>>>>> Spring Data (Geode) Moore > >>>>>> < > >>>> > https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L12 > > > >>>> [9] > >>>>>> (or SDG 2.2 > >>>>>> < > >>>> > https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L10 > > > >>>> [10]); > >>>>>> This is also not arbitrary because Spring Boot 2.2 declares a > dependency > >>>>>> on > >>>>>> < > >>>> > https://github.com/spring-projects/spring-boot/blob/v2.2.0.M5/spring-boot-project/spring-boot-dependencies/pom.xml#L185 > > > >>>> [11] > >>>>>> Spring Data Moore. Again, the stars must align. > >>>>>> 7. Spring Data Geode (SDG) Moore/2.2 is based on > >>>>>> < > >>>> > https://github.com/spring-projects/spring-data-geode/blob/2.2.0.RC2/pom.xml#L25 > > > >>>> [12] > >>>>>> Apache Geode 1.9.0. > >>>>>> 8. As you can see, SDG Moore/2.2 is already in release candidates > (i.e. > >>>>>> RC2 or the 2nd release candidate), which means SDG cannot be > rebased on > >>>>>> 1.10 at this point. The transitive dependency major.minor versions > are > >>>> now > >>>>>> fixed for SD(G) Moore/2.2. > >>>>>> 9. SDG Moore/2.2 can pick up any version of Apache Geode 1.9.x (e.g. > >>>>>> 1.9.1 up to 1.9.N where N is 0... infinity). > >>>>>> > >>>>>> Finally, SDG's next opportunity to pick up Apache Geode 1.10 or > 1.11 or > >>>>>> 1.whatever is in the next SD Release Trains, Neuman, or 2.3. SDG > can > >>>>>> continue to pick up new versions of Apache Geode 1.10, 1.11, 1.12, > etc > >>>>>> until SDG Neuman/2.3 reaches it's first release candidate (RC) > release, > >>>> at > >>>>>> which point the major.minor becomes fixed in that particular SD > Release > >>>>>> Train, until the next SD Release Train (Neuman.next). > >>>>>> > >>>>>> Make sense? > >>>>>> > >>>>>> So, it is the SDG version (along with Spring Boot core) that SBDG > >>>> depends > >>>>>> on that determines the version of Apache Geode that SBDG pulls in. > >>>>>> > >>>>>> Hope this helps! > >>>>>> > >>>>>> Regards, > >>>>>> John > >>>>>> > >>>>>> > >>>>>> [1] > >>>>>> > >>>> > https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17 > >>>>>> [2] > https://github.com/spring-projects/spring-boot-data-geode/releases > >>>>>> [3] > >>>>>> > >>>> > https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L8 > >>>>>> [4] > >>>>>> > >>>> > https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L12 > >>>>>> [5] > >>>>>> > >>>> > https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L10 > >>>>>> [6] > >>>>>> > >>>> > https://github.com/spring-projects/spring-boot/blob/v2.1.7.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L169 > >>>>>> [7] > >>>>>> > >>>> > https://github.com/spring-projects/spring-data-geode/blob/2.1.10.RELEASE/pom.xml#L25 > >>>>>> [8] > >>>>>> > >>>> > https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L8 > >>>>>> [9] > >>>>>> > >>>> > https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L12 > >>>>>> [10] > >>>>>> > >>>> > https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L10 > >>>>>> [11] > >>>>>> > >>>> > https://github.com/spring-projects/spring-boot/blob/v2.2.0.M5/spring-boot-project/spring-boot-dependencies/pom.xml#L185 > >>>>>> [12] > >>>>>> > >>>> > https://github.com/spring-projects/spring-data-geode/blob/2.2.0.RC2/pom.xml#L25 > >>>>>> > >>>>>> > >>>>>> On Tue, Aug 13, 2019 at 12:40 PM Aaron Lindsey <alind...@pivotal.io > > > >>>>>> wrote: > >>>>>> > >>>>>>> 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 > >>>>>>>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> -- > >>>>>> -John > >>>>>> john.blum10101 (skype) > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> -John > >>>>> john.blum10101 (skype) > >>>>> > >>>> > >>>> > >>>> -- > >>>> -John > >>>> john.blum10101 (skype) > >>>> > > > > -- -John john.blum10101 (skype)
