Re: [DISCUSS] and the NEW Apache Geode 1.7.0 release branch has been created
+1 to revert and fix on develop On Wed, Sep 12, 2018, 4:43 PM Nabarun Nag wrote: > Reverting them on release/1.7.0 will bring it to the previous status quo, > how all previous releases were done. I don't think anyone will build > release/1.7.0 repeatedly, hence there is no advantage of making build > process faster for that branch. > Whereas on develop a more appropriate solution can be incorporated after > discussions. > > Is it acceptable? > > Regards > Nabarun Nag > > On Wed, Sep 12, 2018 at 4:37 PM Patrick Rhomberg > wrote: > > > Okay. So that information is definitely coming from the > > GemFireVersion.properties file, which explains this issue. Either > > reverting the previous GEODE-5600 changes or resolving merge conflicts > from > > PR 2457 would address this issue. > > > > My concern remains about the .buildinfo file, however.Is the > .buildinfo > > redundant at this point and should be? Should it always contain the > > necessary information, with the GemFireVersion.properties file acquiring > > the source information from .buildinfo rather than fetching it again > > itself? Is .buildinfo a convention in distributions with which I am just > > myself unfamiliar? > > > > The path we take here is fundamentally linked to how we want to approach > > GEODE-5600, and with PR 2457 currently open, we could choose any of these > > routes to go. > > > > On Wed, Sep 12, 2018 at 4:13 PM, Nabarun Nag wrote: > > > > > @patrick > > > if you build geode release branch 1.7.0 "./gradlew clean build > > > -Dskip.tests=true -xdocs -xjavadoc" and start gfsh from > > > geode-assembly/build/install/apache-geode/bin/gfsh > > > And then type `version --full` you get this > > > > > > gfsh>version --full > > > Build-Date: 2018-09-12 16:07:03 -0700 > > > Build-Id: nnag 0 > > > Build-Java-Version: 1.8.0_181 > > > Build-Platform: Mac OS X 10.13.6 x86_64 > > > Product-Name: Apache Geode > > > Product-Version: 1.7.0 > > > Source-Date: 2018-09-12 16:07:03 -0700 > > > *Source-Repository: unknown* > > > *Source-Revision: unknown* > > > Native version: native code unavailable > > > Running on: /10.118.19.23, 8 cpu(s), x86_64 Mac OS X 10.13.6 > > > > > > As you can notice that Source-Repository and Source-Revision is > missing. > > It > > > should contain the info from the buildinfo file present in > > > geode-assemble/.buildinfo file. It contains the following > > > > > > # > > > #Wed Sep 12 16:07:56 PDT 2018 > > > Source-Date=2018-09-11 15\:56\:48 -0700 > > > Source-Revision=c637193aa61abdfd236ae36b6d9a228fc1e84bcd > > > Source-Repository=release/1.7.0 > > > > > > Hope this helps > > > > > > Regards > > > Nabarun Nag > > > > > > On Wed, Sep 12, 2018 at 3:51 PM Patrick Rhomberg > > > > wrote: > > > > > > > I'm happy to work on those reverts, although if Anthony could > elaborate > > > on > > > > where exactly the version information was missing, that assuage some > of > > > my > > > > own worries as to whether it's the right approach. It's still not > > clear > > > to > > > > me where .buildinfo is intended to be consumed. > > > > > > > > On Wed, Sep 12, 2018 at 3:08 PM, Nabarun Nag > wrote: > > > > > > > > > Yes Alexander, we are still waiting on the build info reverts from > > > > Patrick, > > > > > so, I think that this can be put into release/1.7.0. > > > > > > > > > > Sure Jinmei, you can go ahead and merge the change into > release/1.7.0 > > > > > branch too when you merge the PR. Please do close the fixed version > > in > > > > the > > > > > JIRA as 1.7.0 > > > > > > > > > > Regards > > > > > Nabarun Nag > > > > > > > > > > > > > > > On Wed, Sep 12, 2018 at 2:50 PM Alexander Murmann < > > amurm...@pivotal.io > > > > > > > > > wrote: > > > > > > > > > > > While there is a workaround this looks like a highly visible bug > > > with a > > > > > > fairly safe fix. I am in favor of merging, since the branch is > > still > > > > > > distressed anyways. > > > > > > > > > > > > Other opinions? > > > > > > > > > > > > On Wed, Sep 12, 2018 at 2:29 PM, Jinmei Liao > > > > wrote: > > > > > > > > > > > > > Should we include the fix for GEODE-5727 in the 1.7 release as > > > well? > > > > > > > > > > > > > > Without the fix, the command "export cluster-config > > > > > > --zip-file-name=x.zip" > > > > > > > would fail with NPE, user has to use "export cluster-config > > > > > > > --zip-file-name=./x.zip" in order for export to work. > > > > > > > > > > > > > > PR for this fix is ready and could be merged soon. > > > > > > > > > > > > > > Jinmei > > > > > > > > > > > > > > > > > > > > > On Wed, Sep 12, 2018 at 11:12 AM Patrick Rhomberg < > > > > > prhomb...@apache.org> > > > > > > > wrote: > > > > > > > > > > > > > > > I'm not sure PR 2457 will help with an ignored .buildinfo, > but > > > I'm > > > > > not > > > > > > > sure > > > > > > > > as to why .buildinfo would be getting ignored by anything, > > > either. > > > > > > > > > > > > > > > > PR 2457 deals with the still-needs-to-be-renamed > > > > > > > GemFireVersion.prop
Re: [DISCUSS] and the NEW Apache Geode 1.7.0 release branch has been created
Sounds like we have a plan! I'll take it upon myself to do the revert. On Thu, Sep 13, 2018 at 7:24 AM, Sai Boorlagadda wrote: > +1 to revert and fix on develop > > On Wed, Sep 12, 2018, 4:43 PM Nabarun Nag wrote: > > > Reverting them on release/1.7.0 will bring it to the previous status quo, > > how all previous releases were done. I don't think anyone will build > > release/1.7.0 repeatedly, hence there is no advantage of making build > > process faster for that branch. > > Whereas on develop a more appropriate solution can be incorporated after > > discussions. > > > > Is it acceptable? > > > > Regards > > Nabarun Nag > > > > On Wed, Sep 12, 2018 at 4:37 PM Patrick Rhomberg > > wrote: > > > > > Okay. So that information is definitely coming from the > > > GemFireVersion.properties file, which explains this issue. Either > > > reverting the previous GEODE-5600 changes or resolving merge conflicts > > from > > > PR 2457 would address this issue. > > > > > > My concern remains about the .buildinfo file, however.Is the > > .buildinfo > > > redundant at this point and should be? Should it always contain the > > > necessary information, with the GemFireVersion.properties file > acquiring > > > the source information from .buildinfo rather than fetching it again > > > itself? Is .buildinfo a convention in distributions with which I am > just > > > myself unfamiliar? > > > > > > The path we take here is fundamentally linked to how we want to > approach > > > GEODE-5600, and with PR 2457 currently open, we could choose any of > these > > > routes to go. > > > > > > On Wed, Sep 12, 2018 at 4:13 PM, Nabarun Nag wrote: > > > > > > > @patrick > > > > if you build geode release branch 1.7.0 "./gradlew clean build > > > > -Dskip.tests=true -xdocs -xjavadoc" and start gfsh from > > > > geode-assembly/build/install/apache-geode/bin/gfsh > > > > And then type `version --full` you get this > > > > > > > > gfsh>version --full > > > > Build-Date: 2018-09-12 16:07:03 -0700 > > > > Build-Id: nnag 0 > > > > Build-Java-Version: 1.8.0_181 > > > > Build-Platform: Mac OS X 10.13.6 x86_64 > > > > Product-Name: Apache Geode > > > > Product-Version: 1.7.0 > > > > Source-Date: 2018-09-12 16:07:03 -0700 > > > > *Source-Repository: unknown* > > > > *Source-Revision: unknown* > > > > Native version: native code unavailable > > > > Running on: /10.118.19.23, 8 cpu(s), x86_64 Mac OS X 10.13.6 > > > > > > > > As you can notice that Source-Repository and Source-Revision is > > missing. > > > It > > > > should contain the info from the buildinfo file present in > > > > geode-assemble/.buildinfo file. It contains the following > > > > > > > > # > > > > #Wed Sep 12 16:07:56 PDT 2018 > > > > Source-Date=2018-09-11 15\:56\:48 -0700 > > > > Source-Revision=c637193aa61abdfd236ae36b6d9a228fc1e84bcd > > > > Source-Repository=release/1.7.0 > > > > > > > > Hope this helps > > > > > > > > Regards > > > > Nabarun Nag > > > > > > > > On Wed, Sep 12, 2018 at 3:51 PM Patrick Rhomberg < > prhomb...@pivotal.io > > > > > > > wrote: > > > > > > > > > I'm happy to work on those reverts, although if Anthony could > > elaborate > > > > on > > > > > where exactly the version information was missing, that assuage > some > > of > > > > my > > > > > own worries as to whether it's the right approach. It's still not > > > clear > > > > to > > > > > me where .buildinfo is intended to be consumed. > > > > > > > > > > On Wed, Sep 12, 2018 at 3:08 PM, Nabarun Nag > > wrote: > > > > > > > > > > > Yes Alexander, we are still waiting on the build info reverts > from > > > > > Patrick, > > > > > > so, I think that this can be put into release/1.7.0. > > > > > > > > > > > > Sure Jinmei, you can go ahead and merge the change into > > release/1.7.0 > > > > > > branch too when you merge the PR. Please do close the fixed > version > > > in > > > > > the > > > > > > JIRA as 1.7.0 > > > > > > > > > > > > Regards > > > > > > Nabarun Nag > > > > > > > > > > > > > > > > > > On Wed, Sep 12, 2018 at 2:50 PM Alexander Murmann < > > > amurm...@pivotal.io > > > > > > > > > > > wrote: > > > > > > > > > > > > > While there is a workaround this looks like a highly visible > bug > > > > with a > > > > > > > fairly safe fix. I am in favor of merging, since the branch is > > > still > > > > > > > distressed anyways. > > > > > > > > > > > > > > Other opinions? > > > > > > > > > > > > > > On Wed, Sep 12, 2018 at 2:29 PM, Jinmei Liao < > jil...@pivotal.io> > > > > > wrote: > > > > > > > > > > > > > > > Should we include the fix for GEODE-5727 in the 1.7 release > as > > > > well? > > > > > > > > > > > > > > > > Without the fix, the command "export cluster-config > > > > > > > --zip-file-name=x.zip" > > > > > > > > would fail with NPE, user has to use "export cluster-config > > > > > > > > --zip-file-name=./x.zip" in order for export to work. > > > > > > > > > > > > > > > > PR for this fix is ready and could be merged soon. > > > > > > > > > > > > > > > > Jinmei > > > > > > > > > > > >
Re: [DISCUSS] and the NEW Apache Geode 1.7.0 release branch has been created
Thank you Patrick. Please do send a notification email once this is reverted in the release/1.7.0 branch. Thank you Jinmei for putting the fix for GEODE-5727 into release/1.7.0. However the GEODE ticket is still in open state. Can it be closed? Regards Nabarun Nag On Thu, Sep 13, 2018 at 9:21 AM Patrick Rhomberg wrote: > Sounds like we have a plan! I'll take it upon myself to do the revert. > > On Thu, Sep 13, 2018 at 7:24 AM, Sai Boorlagadda < > sai.boorlaga...@gmail.com> > wrote: > > > +1 to revert and fix on develop > > > > On Wed, Sep 12, 2018, 4:43 PM Nabarun Nag wrote: > > > > > Reverting them on release/1.7.0 will bring it to the previous status > quo, > > > how all previous releases were done. I don't think anyone will build > > > release/1.7.0 repeatedly, hence there is no advantage of making build > > > process faster for that branch. > > > Whereas on develop a more appropriate solution can be incorporated > after > > > discussions. > > > > > > Is it acceptable? > > > > > > Regards > > > Nabarun Nag > > > > > > On Wed, Sep 12, 2018 at 4:37 PM Patrick Rhomberg > > > > wrote: > > > > > > > Okay. So that information is definitely coming from the > > > > GemFireVersion.properties file, which explains this issue. Either > > > > reverting the previous GEODE-5600 changes or resolving merge > conflicts > > > from > > > > PR 2457 would address this issue. > > > > > > > > My concern remains about the .buildinfo file, however.Is the > > > .buildinfo > > > > redundant at this point and should be? Should it always contain the > > > > necessary information, with the GemFireVersion.properties file > > acquiring > > > > the source information from .buildinfo rather than fetching it again > > > > itself? Is .buildinfo a convention in distributions with which I am > > just > > > > myself unfamiliar? > > > > > > > > The path we take here is fundamentally linked to how we want to > > approach > > > > GEODE-5600, and with PR 2457 currently open, we could choose any of > > these > > > > routes to go. > > > > > > > > On Wed, Sep 12, 2018 at 4:13 PM, Nabarun Nag > wrote: > > > > > > > > > @patrick > > > > > if you build geode release branch 1.7.0 "./gradlew clean build > > > > > -Dskip.tests=true -xdocs -xjavadoc" and start gfsh from > > > > > geode-assembly/build/install/apache-geode/bin/gfsh > > > > > And then type `version --full` you get this > > > > > > > > > > gfsh>version --full > > > > > Build-Date: 2018-09-12 16:07:03 -0700 > > > > > Build-Id: nnag 0 > > > > > Build-Java-Version: 1.8.0_181 > > > > > Build-Platform: Mac OS X 10.13.6 x86_64 > > > > > Product-Name: Apache Geode > > > > > Product-Version: 1.7.0 > > > > > Source-Date: 2018-09-12 16:07:03 -0700 > > > > > *Source-Repository: unknown* > > > > > *Source-Revision: unknown* > > > > > Native version: native code unavailable > > > > > Running on: /10.118.19.23, 8 cpu(s), x86_64 Mac OS X 10.13.6 > > > > > > > > > > As you can notice that Source-Repository and Source-Revision is > > > missing. > > > > It > > > > > should contain the info from the buildinfo file present in > > > > > geode-assemble/.buildinfo file. It contains the following > > > > > > > > > > # > > > > > #Wed Sep 12 16:07:56 PDT 2018 > > > > > Source-Date=2018-09-11 15\:56\:48 -0700 > > > > > Source-Revision=c637193aa61abdfd236ae36b6d9a228fc1e84bcd > > > > > Source-Repository=release/1.7.0 > > > > > > > > > > Hope this helps > > > > > > > > > > Regards > > > > > Nabarun Nag > > > > > > > > > > On Wed, Sep 12, 2018 at 3:51 PM Patrick Rhomberg < > > prhomb...@pivotal.io > > > > > > > > > wrote: > > > > > > > > > > > I'm happy to work on those reverts, although if Anthony could > > > elaborate > > > > > on > > > > > > where exactly the version information was missing, that assuage > > some > > > of > > > > > my > > > > > > own worries as to whether it's the right approach. It's still > not > > > > clear > > > > > to > > > > > > me where .buildinfo is intended to be consumed. > > > > > > > > > > > > On Wed, Sep 12, 2018 at 3:08 PM, Nabarun Nag > > > wrote: > > > > > > > > > > > > > Yes Alexander, we are still waiting on the build info reverts > > from > > > > > > Patrick, > > > > > > > so, I think that this can be put into release/1.7.0. > > > > > > > > > > > > > > Sure Jinmei, you can go ahead and merge the change into > > > release/1.7.0 > > > > > > > branch too when you merge the PR. Please do close the fixed > > version > > > > in > > > > > > the > > > > > > > JIRA as 1.7.0 > > > > > > > > > > > > > > Regards > > > > > > > Nabarun Nag > > > > > > > > > > > > > > > > > > > > > On Wed, Sep 12, 2018 at 2:50 PM Alexander Murmann < > > > > amurm...@pivotal.io > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > While there is a workaround this looks like a highly visible > > bug > > > > > with a > > > > > > > > fairly safe fix. I am in favor of merging, since the branch > is > > > > still > > > > > > > > distressed anyways. > > > > > > > > > > > > > > > > Other opinions
Re: [DISCUSS] and the NEW Apache Geode 1.7.0 release branch has been created
GEODE-5727 is closed and merged to release/1.7.0 Thank you Jinmei On Thu, Sep 13, 2018 at 9:47 AM Nabarun Nag wrote: > Thank you Patrick. Please do send a notification email once this is > reverted in the release/1.7.0 branch. > Thank you Jinmei for putting the fix for GEODE-5727 into release/1.7.0. > However the GEODE ticket is still in open state. Can it be closed? > > Regards > Nabarun Nag > > > On Thu, Sep 13, 2018 at 9:21 AM Patrick Rhomberg > wrote: > >> Sounds like we have a plan! I'll take it upon myself to do the revert. >> >> On Thu, Sep 13, 2018 at 7:24 AM, Sai Boorlagadda < >> sai.boorlaga...@gmail.com> >> wrote: >> >> > +1 to revert and fix on develop >> > >> > On Wed, Sep 12, 2018, 4:43 PM Nabarun Nag wrote: >> > >> > > Reverting them on release/1.7.0 will bring it to the previous status >> quo, >> > > how all previous releases were done. I don't think anyone will build >> > > release/1.7.0 repeatedly, hence there is no advantage of making build >> > > process faster for that branch. >> > > Whereas on develop a more appropriate solution can be incorporated >> after >> > > discussions. >> > > >> > > Is it acceptable? >> > > >> > > Regards >> > > Nabarun Nag >> > > >> > > On Wed, Sep 12, 2018 at 4:37 PM Patrick Rhomberg < >> prhomb...@pivotal.io> >> > > wrote: >> > > >> > > > Okay. So that information is definitely coming from the >> > > > GemFireVersion.properties file, which explains this issue. Either >> > > > reverting the previous GEODE-5600 changes or resolving merge >> conflicts >> > > from >> > > > PR 2457 would address this issue. >> > > > >> > > > My concern remains about the .buildinfo file, however.Is the >> > > .buildinfo >> > > > redundant at this point and should be? Should it always contain the >> > > > necessary information, with the GemFireVersion.properties file >> > acquiring >> > > > the source information from .buildinfo rather than fetching it again >> > > > itself? Is .buildinfo a convention in distributions with which I am >> > just >> > > > myself unfamiliar? >> > > > >> > > > The path we take here is fundamentally linked to how we want to >> > approach >> > > > GEODE-5600, and with PR 2457 currently open, we could choose any of >> > these >> > > > routes to go. >> > > > >> > > > On Wed, Sep 12, 2018 at 4:13 PM, Nabarun Nag >> wrote: >> > > > >> > > > > @patrick >> > > > > if you build geode release branch 1.7.0 "./gradlew clean build >> > > > > -Dskip.tests=true -xdocs -xjavadoc" and start gfsh from >> > > > > geode-assembly/build/install/apache-geode/bin/gfsh >> > > > > And then type `version --full` you get this >> > > > > >> > > > > gfsh>version --full >> > > > > Build-Date: 2018-09-12 16:07:03 -0700 >> > > > > Build-Id: nnag 0 >> > > > > Build-Java-Version: 1.8.0_181 >> > > > > Build-Platform: Mac OS X 10.13.6 x86_64 >> > > > > Product-Name: Apache Geode >> > > > > Product-Version: 1.7.0 >> > > > > Source-Date: 2018-09-12 16:07:03 -0700 >> > > > > *Source-Repository: unknown* >> > > > > *Source-Revision: unknown* >> > > > > Native version: native code unavailable >> > > > > Running on: /10.118.19.23, 8 cpu(s), x86_64 Mac OS X 10.13.6 >> > > > > >> > > > > As you can notice that Source-Repository and Source-Revision is >> > > missing. >> > > > It >> > > > > should contain the info from the buildinfo file present in >> > > > > geode-assemble/.buildinfo file. It contains the following >> > > > > >> > > > > # >> > > > > #Wed Sep 12 16:07:56 PDT 2018 >> > > > > Source-Date=2018-09-11 15\:56\:48 -0700 >> > > > > Source-Revision=c637193aa61abdfd236ae36b6d9a228fc1e84bcd >> > > > > Source-Repository=release/1.7.0 >> > > > > >> > > > > Hope this helps >> > > > > >> > > > > Regards >> > > > > Nabarun Nag >> > > > > >> > > > > On Wed, Sep 12, 2018 at 3:51 PM Patrick Rhomberg < >> > prhomb...@pivotal.io >> > > > >> > > > > wrote: >> > > > > >> > > > > > I'm happy to work on those reverts, although if Anthony could >> > > elaborate >> > > > > on >> > > > > > where exactly the version information was missing, that assuage >> > some >> > > of >> > > > > my >> > > > > > own worries as to whether it's the right approach. It's still >> not >> > > > clear >> > > > > to >> > > > > > me where .buildinfo is intended to be consumed. >> > > > > > >> > > > > > On Wed, Sep 12, 2018 at 3:08 PM, Nabarun Nag >> > > wrote: >> > > > > > >> > > > > > > Yes Alexander, we are still waiting on the build info reverts >> > from >> > > > > > Patrick, >> > > > > > > so, I think that this can be put into release/1.7.0. >> > > > > > > >> > > > > > > Sure Jinmei, you can go ahead and merge the change into >> > > release/1.7.0 >> > > > > > > branch too when you merge the PR. Please do close the fixed >> > version >> > > > in >> > > > > > the >> > > > > > > JIRA as 1.7.0 >> > > > > > > >> > > > > > > Regards >> > > > > > > Nabarun Nag >> > > > > > > >> > > > > > > >> > > > > > > On Wed, Sep 12, 2018 at 2:50 PM Alexander Murmann < >> > > > amurm...@pivotal.io >> > > > > > >> > > > > > > wrote
[PROPOSAL] Change Geode Log4J2 appenders to avoid programmatic add/remove
Geode currently manipulates Log4J2 at runtime to add/remove Appenders based on the Cache lifecycle. While working on GEODE-5637, Sai and I tried to add ListAppender [1] from log4j-core test-jar programmatically at runtime using the same code that Geode uses for AlertAppender, LogWriterAppender and removing/adding STDOUT ConsoleAppender. Unfortunately, this behavior seems to either have never worked completely or was broken by one of the Log4J2 dependency upgrades over the last couple years. In my opinion, it doesn't make sense to continue in this direction. GEODE-2644 describes an alternate approach which would be easier to maintain and more user-friendly in the long-run, so I'm planning to change the Geode appenders as described by GEODE-2644 and then add debug functionality to the Geode appenders which tests such as this can use for easier testing. Old approach: The Geode Appenders are added or removed when the Cache is created or closed. Geode uses Log4J2 Core APIs to reconfigure and updateLoggers, but updating of static loggers doesn't seem to be working as intended. New approach: The Geode Appenders would remain registered throughout the life of the JVM. The Appenders will contain mutable state that allows Geode to change its internal configuration or enable/disable output without resorting to programmatically reconfiguring Log4J2 at runtime to add/remove Appenders. We would also make the Geode Appenders optional and configurable from log4j2.xml, which allows users to use a different back-end such as Logback with Geode or to more easily tweak behavior of these Appenders when using Log4J2. I think this actually ends up being less work both in the short-run and long-run than trying to fixup the current approach. If anyone has concerns or opinions or wants to be involved, please reply to this thread. Thanks! [1] https://issues.apache.org/jira/browse/GEODE-5637 [2] https://relentlesscoding.com/2018/04/21/unit-test-log4j2-log-output/ [3] https://issues.apache.org/jira/browse/GEODE-2644
Re: [DISCUSS] and the NEW Apache Geode 1.7.0 release branch has been created
Revert of 5600 commits pushed to release/1.7.0. Built clean locally and `$> gfsh version --full` is behaving as expected. On Thu, Sep 13, 2018 at 9:49 AM, Nabarun Nag wrote: > GEODE-5727 is closed and merged to release/1.7.0 > Thank you Jinmei > > On Thu, Sep 13, 2018 at 9:47 AM Nabarun Nag wrote: > > > Thank you Patrick. Please do send a notification email once this is > > reverted in the release/1.7.0 branch. > > Thank you Jinmei for putting the fix for GEODE-5727 into release/1.7.0. > > However the GEODE ticket is still in open state. Can it be closed? > > > > Regards > > Nabarun Nag > > > > > > On Thu, Sep 13, 2018 at 9:21 AM Patrick Rhomberg > > wrote: > > > >> Sounds like we have a plan! I'll take it upon myself to do the revert. > >> > >> On Thu, Sep 13, 2018 at 7:24 AM, Sai Boorlagadda < > >> sai.boorlaga...@gmail.com> > >> wrote: > >> > >> > +1 to revert and fix on develop > >> > > >> > On Wed, Sep 12, 2018, 4:43 PM Nabarun Nag wrote: > >> > > >> > > Reverting them on release/1.7.0 will bring it to the previous status > >> quo, > >> > > how all previous releases were done. I don't think anyone will build > >> > > release/1.7.0 repeatedly, hence there is no advantage of making > build > >> > > process faster for that branch. > >> > > Whereas on develop a more appropriate solution can be incorporated > >> after > >> > > discussions. > >> > > > >> > > Is it acceptable? > >> > > > >> > > Regards > >> > > Nabarun Nag > >> > > > >> > > On Wed, Sep 12, 2018 at 4:37 PM Patrick Rhomberg < > >> prhomb...@pivotal.io> > >> > > wrote: > >> > > > >> > > > Okay. So that information is definitely coming from the > >> > > > GemFireVersion.properties file, which explains this issue. Either > >> > > > reverting the previous GEODE-5600 changes or resolving merge > >> conflicts > >> > > from > >> > > > PR 2457 would address this issue. > >> > > > > >> > > > My concern remains about the .buildinfo file, however.Is the > >> > > .buildinfo > >> > > > redundant at this point and should be? Should it always contain > the > >> > > > necessary information, with the GemFireVersion.properties file > >> > acquiring > >> > > > the source information from .buildinfo rather than fetching it > again > >> > > > itself? Is .buildinfo a convention in distributions with which I > am > >> > just > >> > > > myself unfamiliar? > >> > > > > >> > > > The path we take here is fundamentally linked to how we want to > >> > approach > >> > > > GEODE-5600, and with PR 2457 currently open, we could choose any > of > >> > these > >> > > > routes to go. > >> > > > > >> > > > On Wed, Sep 12, 2018 at 4:13 PM, Nabarun Nag > >> wrote: > >> > > > > >> > > > > @patrick > >> > > > > if you build geode release branch 1.7.0 "./gradlew clean build > >> > > > > -Dskip.tests=true -xdocs -xjavadoc" and start gfsh from > >> > > > > geode-assembly/build/install/apache-geode/bin/gfsh > >> > > > > And then type `version --full` you get this > >> > > > > > >> > > > > gfsh>version --full > >> > > > > Build-Date: 2018-09-12 16:07:03 -0700 > >> > > > > Build-Id: nnag 0 > >> > > > > Build-Java-Version: 1.8.0_181 > >> > > > > Build-Platform: Mac OS X 10.13.6 x86_64 > >> > > > > Product-Name: Apache Geode > >> > > > > Product-Version: 1.7.0 > >> > > > > Source-Date: 2018-09-12 16:07:03 -0700 > >> > > > > *Source-Repository: unknown* > >> > > > > *Source-Revision: unknown* > >> > > > > Native version: native code unavailable > >> > > > > Running on: /10.118.19.23, 8 cpu(s), x86_64 Mac OS X 10.13.6 > >> > > > > > >> > > > > As you can notice that Source-Repository and Source-Revision is > >> > > missing. > >> > > > It > >> > > > > should contain the info from the buildinfo file present in > >> > > > > geode-assemble/.buildinfo file. It contains the following > >> > > > > > >> > > > > # > >> > > > > #Wed Sep 12 16:07:56 PDT 2018 > >> > > > > Source-Date=2018-09-11 15\:56\:48 -0700 > >> > > > > Source-Revision=c637193aa61abdfd236ae36b6d9a228fc1e84bcd > >> > > > > Source-Repository=release/1.7.0 > >> > > > > > >> > > > > Hope this helps > >> > > > > > >> > > > > Regards > >> > > > > Nabarun Nag > >> > > > > > >> > > > > On Wed, Sep 12, 2018 at 3:51 PM Patrick Rhomberg < > >> > prhomb...@pivotal.io > >> > > > > >> > > > > wrote: > >> > > > > > >> > > > > > I'm happy to work on those reverts, although if Anthony could > >> > > elaborate > >> > > > > on > >> > > > > > where exactly the version information was missing, that > assuage > >> > some > >> > > of > >> > > > > my > >> > > > > > own worries as to whether it's the right approach. It's still > >> not > >> > > > clear > >> > > > > to > >> > > > > > me where .buildinfo is intended to be consumed. > >> > > > > > > >> > > > > > On Wed, Sep 12, 2018 at 3:08 PM, Nabarun Nag > > >> > > wrote: > >> > > > > > > >> > > > > > > Yes Alexander, we are still waiting on the build info > reverts > >> > from > >> > > > > > Patrick, > >> > > > > > > so, I think that this can be put into release/1.7.0. > >> > > > > > > > >>
Re: [DISCUSS] and the NEW Apache Geode 1.7.0 release branch has been created
Thank you Patrick. Starting with creation of the first release candidate Regards Nabarun Nag On Thu, Sep 13, 2018 at 11:39 AM Patrick Rhomberg wrote: > Revert of 5600 commits pushed to release/1.7.0. Built clean locally and > `$> gfsh version --full` is behaving as expected. > > On Thu, Sep 13, 2018 at 9:49 AM, Nabarun Nag wrote: > > > GEODE-5727 is closed and merged to release/1.7.0 > > Thank you Jinmei > > > > On Thu, Sep 13, 2018 at 9:47 AM Nabarun Nag wrote: > > > > > Thank you Patrick. Please do send a notification email once this is > > > reverted in the release/1.7.0 branch. > > > Thank you Jinmei for putting the fix for GEODE-5727 into release/ > 1.7.0. > > > However the GEODE ticket is still in open state. Can it be closed? > > > > > > Regards > > > Nabarun Nag > > > > > > > > > On Thu, Sep 13, 2018 at 9:21 AM Patrick Rhomberg > > > > wrote: > > > > > >> Sounds like we have a plan! I'll take it upon myself to do the > revert. > > >> > > >> On Thu, Sep 13, 2018 at 7:24 AM, Sai Boorlagadda < > > >> sai.boorlaga...@gmail.com> > > >> wrote: > > >> > > >> > +1 to revert and fix on develop > > >> > > > >> > On Wed, Sep 12, 2018, 4:43 PM Nabarun Nag wrote: > > >> > > > >> > > Reverting them on release/1.7.0 will bring it to the previous > status > > >> quo, > > >> > > how all previous releases were done. I don't think anyone will > build > > >> > > release/1.7.0 repeatedly, hence there is no advantage of making > > build > > >> > > process faster for that branch. > > >> > > Whereas on develop a more appropriate solution can be incorporated > > >> after > > >> > > discussions. > > >> > > > > >> > > Is it acceptable? > > >> > > > > >> > > Regards > > >> > > Nabarun Nag > > >> > > > > >> > > On Wed, Sep 12, 2018 at 4:37 PM Patrick Rhomberg < > > >> prhomb...@pivotal.io> > > >> > > wrote: > > >> > > > > >> > > > Okay. So that information is definitely coming from the > > >> > > > GemFireVersion.properties file, which explains this issue. > Either > > >> > > > reverting the previous GEODE-5600 changes or resolving merge > > >> conflicts > > >> > > from > > >> > > > PR 2457 would address this issue. > > >> > > > > > >> > > > My concern remains about the .buildinfo file, however.Is the > > >> > > .buildinfo > > >> > > > redundant at this point and should be? Should it always contain > > the > > >> > > > necessary information, with the GemFireVersion.properties file > > >> > acquiring > > >> > > > the source information from .buildinfo rather than fetching it > > again > > >> > > > itself? Is .buildinfo a convention in distributions with which > I > > am > > >> > just > > >> > > > myself unfamiliar? > > >> > > > > > >> > > > The path we take here is fundamentally linked to how we want to > > >> > approach > > >> > > > GEODE-5600, and with PR 2457 currently open, we could choose any > > of > > >> > these > > >> > > > routes to go. > > >> > > > > > >> > > > On Wed, Sep 12, 2018 at 4:13 PM, Nabarun Nag > > >> wrote: > > >> > > > > > >> > > > > @patrick > > >> > > > > if you build geode release branch 1.7.0 "./gradlew clean build > > >> > > > > -Dskip.tests=true -xdocs -xjavadoc" and start gfsh from > > >> > > > > geode-assembly/build/install/apache-geode/bin/gfsh > > >> > > > > And then type `version --full` you get this > > >> > > > > > > >> > > > > gfsh>version --full > > >> > > > > Build-Date: 2018-09-12 16:07:03 -0700 > > >> > > > > Build-Id: nnag 0 > > >> > > > > Build-Java-Version: 1.8.0_181 > > >> > > > > Build-Platform: Mac OS X 10.13.6 x86_64 > > >> > > > > Product-Name: Apache Geode > > >> > > > > Product-Version: 1.7.0 > > >> > > > > Source-Date: 2018-09-12 16:07:03 -0700 > > >> > > > > *Source-Repository: unknown* > > >> > > > > *Source-Revision: unknown* > > >> > > > > Native version: native code unavailable > > >> > > > > Running on: /10.118.19.23, 8 cpu(s), x86_64 Mac OS X 10.13.6 > > >> > > > > > > >> > > > > As you can notice that Source-Repository and Source-Revision > is > > >> > > missing. > > >> > > > It > > >> > > > > should contain the info from the buildinfo file present in > > >> > > > > geode-assemble/.buildinfo file. It contains the following > > >> > > > > > > >> > > > > # > > >> > > > > #Wed Sep 12 16:07:56 PDT 2018 > > >> > > > > Source-Date=2018-09-11 15\:56\:48 -0700 > > >> > > > > Source-Revision=c637193aa61abdfd236ae36b6d9a228fc1e84bcd > > >> > > > > Source-Repository=release/1.7.0 > > >> > > > > > > >> > > > > Hope this helps > > >> > > > > > > >> > > > > Regards > > >> > > > > Nabarun Nag > > >> > > > > > > >> > > > > On Wed, Sep 12, 2018 at 3:51 PM Patrick Rhomberg < > > >> > prhomb...@pivotal.io > > >> > > > > > >> > > > > wrote: > > >> > > > > > > >> > > > > > I'm happy to work on those reverts, although if Anthony > could > > >> > > elaborate > > >> > > > > on > > >> > > > > > where exactly the version information was missing, that > > assuage > > >> > some > > >> > > of > > >> > > > > my > > >> > > > > > own worries as to whether it's the right approach. I
Re: [PROPOSAL] Change Geode Log4J2 appenders to avoid programmatic add/remove
+1 on this approach! I'd like to work with you on this to get more familiar with our logging setup. --Jens On Thu, Sep 13, 2018 at 10:01 AM Kirk Lund wrote: > Geode currently manipulates Log4J2 at runtime to add/remove Appenders based > on the Cache lifecycle. While working on GEODE-5637, Sai and I tried to add > ListAppender [1] from log4j-core test-jar programmatically at runtime using > the same code that Geode uses for AlertAppender, LogWriterAppender and > removing/adding STDOUT ConsoleAppender. Unfortunately, this behavior seems > to either have never worked completely or was broken by one of the Log4J2 > dependency upgrades over the last couple years. > > In my opinion, it doesn't make sense to continue in this direction. > GEODE-2644 describes an alternate approach which would be easier to > maintain and more user-friendly in the long-run, so I'm planning to change > the Geode appenders as described by GEODE-2644 and then add debug > functionality to the Geode appenders which tests such as this can use for > easier testing. > > Old approach: The Geode Appenders are added or removed when the Cache is > created or closed. Geode uses Log4J2 Core APIs to reconfigure and > updateLoggers, but updating of static loggers doesn't seem to be working as > intended. > > New approach: The Geode Appenders would remain registered throughout the > life of the JVM. The Appenders will contain mutable state that allows Geode > to change its internal configuration or enable/disable output without > resorting to programmatically reconfiguring Log4J2 at runtime to add/remove > Appenders. > > We would also make the Geode Appenders optional and configurable from > log4j2.xml, which allows users to use a different back-end such as Logback > with Geode or to more easily tweak behavior of these Appenders when using > Log4J2. > > I think this actually ends up being less work both in the short-run and > long-run than trying to fixup the current approach. > > If anyone has concerns or opinions or wants to be involved, please reply to > this thread. > > Thanks! > > [1] https://issues.apache.org/jira/browse/GEODE-5637 > [2] https://relentlesscoding.com/2018/04/21/unit-test-log4j2-log-output/ > [3] https://issues.apache.org/jira/browse/GEODE-2644 >
[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #1039 was SUCCESSFUL (with 2456 tests)
--- Spring Data GemFire > Nightly-ApacheGeode > #1039 was successful. --- Scheduled 2458 tests in total. https://build.spring.io/browse/SGF-NAG-1039/ -- This message is automatically generated by Atlassian Bamboo
