Geode unit tests completed in 'develop/DistributedTest' with non-zero exit code

Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/105

Geode unit tests completed in 'release-1.4.0/DistributedTest' with non-zero exit code

Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/release-1.4.0/jobs/DistributedTest/builds/16

Geode unit tests completed in 'develop/IntegrationTest' with non-zero exit code

Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/148

Geode unit tests completed in 'release-1.4.0/DistributedTest' with non-zero exit code

Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/release-1.4.0/jobs/DistributedTest/builds/15

Geode unit tests completed in 'develop/IntegrationTest' with non-zero exit code

Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/147

Geode unit tests completed in 'develop/FlakyTest' with non-zero exit code

Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/158

[PROPOSAL] Feature flag for multiple caches in the same JVM

We're trying to remove singletons from the system as part of GEODE-3583. I propose adding a feature flag to allow multiple geode caches in the same JVM, and using that to build out tests that our features work without relying on a singletons. I made a PR to this affect - https://github.com/apache/

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #809 was SUCCESSFUL (with 2324 tests)

--- Spring Data GemFire > Nightly-ApacheGeode > #809 was successful. --- Scheduled 2326 tests in total. https://build.spring.io/browse/SGF-NAG-809/ -- This

Geode unit tests completed in 'develop/IntegrationTest' with non-zero exit code

Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/146

Re: [PROPOSAL]: Adding declarable support in Gfsh command

Yes, we are debating the necessity of the "?". -1 on the non-json syntax though. we don't want to implement a new parser ourselves to gather the properties. As to Nick's point about a generic solution that would cover initializing not just Declarable, yes, the syntax itself does not lock down to

Re: [PROPOSAL]: Adding declarable support in Gfsh command

+1 for ability to pass in simple key-value pairs. Would it be possible to loose the "?" between the class name and the json though? Also, since we are essentially trying to pass a java.util.Properties object to the Declarable, would it be better if we ask the users to pass-in a string representati

Re: [PROPOSAL]: Adding declarable support in Gfsh command

This would solve the problem of specifying the parameters for a Declarable, but if you provided support for any valid json, you could cover other situations as well, including those with more complicated and possibly nested configuration. If we would ever support such scenarios in the future, I ass

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

Correct, that is what this ticket is asking for. > On Jan 26, 2018, at 10:09 AM, Anilkumar Gingade wrote: > > Jake, the requirement seems like users doesn't have to set the > read-serialized flag; system needs to take care of that based on > availability of domain-class in classpath. > > -Anil.

Re: [PROPOSAL]: Adding declarable support in Gfsh command

+1 Currently passing properties is supported with AsyncEventListener with "-listener-param" option, we need make it consistent across the call-backs. -Anil. On Fri, Jan 26, 2018 at 8:43 AM, Jens Deppe wrote: > This also avoids the other option of implementing this by having associated > 'param

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

Jake, the requirement seems like users doesn't have to set the read-serialized flag; system needs to take care of that based on availability of domain-class in classpath. -Anil. On Thu, Jan 25, 2018 at 2:01 PM, Jacob Barrett wrote: > It is no different really than how the Java client works. I

Re: jacocoTestReport

Specify `-PcodeCoverage=true` on your build command. > On Jan 26, 2018, at 9:42 AM, Kirk Lund wrote: > > gradle/code-analysis.gradle contains configuration for the jacoco plugin, > but if I attempt to execute the standard jacoco task jacocoTestReport, our > build just fails and says it doesn't k

jacocoTestReport

gradle/code-analysis.gradle contains configuration for the jacoco plugin, but if I attempt to execute the standard jacoco task jacocoTestReport, our build just fails and says it doesn't know what that is. How do we run jacoco on the command line? I tried this: ./gradlew geode-core:test --tests *

Re: [PROPOSAL]: Adding declarable support in Gfsh command

This also avoids the other option of implementing this by having associated 'params' options for each option which can take a Declarable, thus reducing the proliferation of options - in particular for 'create region'. i.e. --cache-listener AND --cache-listener-params. Further, this json parameter

[PROPOSAL]: Adding declarable support in Gfsh command

Currently, when you want to specify a call-back in gfsh command option, you can only pass in the class name, e.g.: create region --name=regionA --type=PARTITION --cache-loader=my.CacheLoader But these callbacks all implements Declarable (CacheLoader, CacheWriter, CacheListener, CustomExpiry etc.)