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.)
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
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 *
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
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
+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
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.
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
+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
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
Pipeline results can be found at:
Concourse:
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/146
---
Spring Data GemFire > Nightly-ApacheGeode > #809 was successful.
---
Scheduled
2326 tests in total.
https://build.spring.io/browse/SGF-NAG-809/
--
This
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/
Pipeline results can be found at:
Concourse:
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/158
Pipeline results can be found at:
Concourse:
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/147
Pipeline results can be found at:
Concourse:
https://concourse.apachegeode-ci.info/teams/main/pipelines/release-1.4.0/jobs/DistributedTest/builds/15
Pipeline results can be found at:
Concourse:
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/148
Pipeline results can be found at:
Concourse:
https://concourse.apachegeode-ci.info/teams/main/pipelines/release-1.4.0/jobs/DistributedTest/builds/16
Pipeline results can be found at:
Concourse:
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/105
19 matches
Mail list logo