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)
