Re: [PROPOSAL]: Adding declarable support in Gfsh command
We are removing the "?" in the syntax and continue on this route of
implementation: className followed by the json representation of the
properties to initialize the class.
A pull request has been opened regarding this:
https://github.com/apache/geode/pull/1327
On Fri, Jan 26, 2018 at 12:38 PM, Jinmei Liao wrote:
> 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 the class
> being a Declarable. However you want to configure the object using the
> parsed Property, it's up to how we want to interpret this property. Our
> current implementation only support using this property if the className
> specified is a Declarable, but we can enhance it to support other types as
> well.
>
>
>
> On Fri, Jan 26, 2018 at 12:15 PM, Swapnil Bawaskar
> wrote:
>
>> +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 representation of the properties object? something like:
>> --cache-loader=my.CacheLoader{key2=value2, key1=value1}
>> A parenthesis around the values may also help in conveying the intention:
>> --cache-loader=my.CacheLoader({key2=value2, key1=value1})
>>
>> On Fri, Jan 26, 2018 at 10:24 AM Nick Reich wrote:
>>
>> > 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 assume that we would want a generic solution that would cover
>> all
>> > configuration. Is this something that we anticipate needing and if so,
>> how
>> > would the current proposal cover such situations?
>> >
>> > On Fri, Jan 26, 2018 at 8:43 AM, Jens Deppe wrote:
>> >
>> > > 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 would not allow for arbitrary json but
>> would
>> > > be restricted to a simple key/value mapping so that there would be a
>> > direct
>> > > translation to Declarable parameters in the cache.xml.
>> > >
>> > > --Jens
>> > >
>> > > On Fri, Jan 26, 2018 at 8:07 AM, Jinmei Liao
>> wrote:
>> > >
>> > > > 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.), i.e they can initialized with
>> extra
>> > > > properties that can be set when they are declared in cache.xml, but
>> > > > currently, our gfsh command doesn't support that.
>> > > >
>> > > > We are proposing to add the support to configure Declarables in gfsh
>> > > > commands by adding json strings at the end of the class name. like
>> > this:
>> > > >
>> > > > create region --name=regionA --type=PARTITION
>> > > > --cache-loader=my.CacheLoader?{"key":"value,"key2":"value2"}
>> > > >
>> > > > (of course, if you don't need to configure your Declarable, you can
>> > still
>> > > > only specify a className as before).
>> > > >
>> > > > Comments/thoughts?
>> > > >
>> > > > --
>> > > > Cheers
>> > > >
>> > > > Jinmei
>> > > >
>> > >
>> >
>>
>
>
>
> --
> Cheers
>
> Jinmei
>
--
Cheers
Jinmei
upgrading a DataSerializable
I would like to change the ExpirationAction to a true Enum object, but this class is used by ExpirationAttributes which is a DataSerializable, and making the change fails the rolling upgrade tests. Anyone knows a good example that I can follow to update a DataSerializable object? Specifically, how do I implement the fromData and toData call? Thanks! -- Cheers Jinmei
Re: upgrading a DataSerializable
https://cwiki.apache.org/confluence/display/GEODE/Managing+Backward+Compatibility On 1/29/18 8:59 AM, Jinmei Liao wrote: I would like to change the ExpirationAction to a true Enum object, but this class is used by ExpirationAttributes which is a DataSerializable, and making the change fails the rolling upgrade tests. Anyone knows a good example that I can follow to update a DataSerializable object? Specifically, how do I implement the fromData and toData call? Thanks!
Geode Website Docs page: Proposal to limit the number of versions listed.
Question: How many versions of the User Documentation and the Javadocs do we need to see on the Geode Docs page (http://geode.apache.org/docs)? The current scheme has two policies: - For the User Documentation, there's a link for each of four versions: 1.0, 1.1, 1.2 and 1.3. There will soon be a fifth bullet for v1.4. - For the Javadocs, there's only one link which points to the latest version, currently 1.3. Users who need earlier versions can presumably find them among their own copies of the source code. Proposal: - Shorten the list for the User Documentation, showing only the three most recent versions - No change for the Javadocs, link to only the most recent version What do you think?
Re: Geode Website Docs page: Proposal to limit the number of versions listed.
I'm fine with the proposal. It would be nice if there was a way to navigate to user documentation for older versions; perhaps just rely on Google? ;) Sarge > On 29 Jan, 2018, at 10:39, Dave Barnes wrote: > > Question: > How many versions of the User Documentation and the Javadocs do we need to > see on the Geode Docs page (http://geode.apache.org/docs)? > > The current scheme has two policies: > - For the User Documentation, there's a link for each of four versions: > 1.0, 1.1, 1.2 and 1.3. There will soon be a fifth bullet for v1.4. > - For the Javadocs, there's only one link which points to the latest > version, currently 1.3. Users who need earlier versions can presumably find > them among their own copies of the source code. > > Proposal: > - Shorten the list for the User Documentation, showing only the three most > recent versions > - No change for the Javadocs, link to only the most recent version > > What do you think?
Re: Geode Website Docs page: Proposal to limit the number of versions listed.
Maybe we could have a link at the bottom that goes to a full list? On Mon, Jan 29, 2018 at 11:10 AM, Michael William Dodge wrote: > I'm fine with the proposal. It would be nice if there was a way to > navigate to user documentation for older versions; perhaps just rely on > Google? ;) > > Sarge > > > On 29 Jan, 2018, at 10:39, Dave Barnes wrote: > > > > Question: > > How many versions of the User Documentation and the Javadocs do we need > to > > see on the Geode Docs page (http://geode.apache.org/docs)? > > > > The current scheme has two policies: > > - For the User Documentation, there's a link for each of four versions: > > 1.0, 1.1, 1.2 and 1.3. There will soon be a fifth bullet for v1.4. > > - For the Javadocs, there's only one link which points to the latest > > version, currently 1.3. Users who need earlier versions can presumably > find > > them among their own copies of the source code. > > > > Proposal: > > - Shorten the list for the User Documentation, showing only the three > most > > recent versions > > - No change for the Javadocs, link to only the most recent version > > > > What do you think? > >
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/107
[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #812 was SUCCESSFUL (with 2324 tests)
--- Spring Data GemFire > Nightly-ApacheGeode > #812 was successful. --- Scheduled 2326 tests in total. https://build.spring.io/browse/SGF-NAG-812/ -- This message is automatically generated by Atlassian Bamboo
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/164
[VOTE] Apache Geode release - 1.4.0 RC2
After fixing the security concerns in the first release candidate, this is the second release candidate for Apache Geode, version 1.4.0. Thanks to all the community members for their contributions to this release! *** Please download, test and vote by Thursday, Feb 1, 1400 hrs US Pacific. *** It fixes 277 issues. release notes can be found at: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420&version=12341842 Note that we are voting upon the source tags: rel/v1.4.0.RC2 https://github.com/apache/geode/tree/rel/v1.4.0.RC2 https://github.com/apache/geode-examples/tree/rel/v1.4.0.RC2 Commit ID: 2a70679608120042fa7cbee67f4dd21a085d9588 (geode) ced35f88173b04ac8e104b9cae10cc38289675fa (geode-examples) Source and binary files: https://dist.apache.org/repos/dist/dev/geode/1.4.0.RC2 Maven staging repo: https://repository.apache.org/content/repositories/orgapachegeode-1037 Geode's KEYS file containing PGP keys we use to sign the release: https://github.com/apache/geode/blob/develop/KEYS Release Signed with Key: pub 4096R/18F902DB 2016-04-07 Fingerprint: E1B1 ABE3 4753 E7BA 8097 4285 8F8F 2BCC 18F9 02DB
Re: [VOTE] Apache Geode release - 1.4.0 RC2
+1 Looks good to me. Ran geode-release-check, verified potential security issue is resolved, concourse job passed. -Dan On Mon, Jan 29, 2018 at 4:08 PM, Swapnil Bawaskar wrote: > After fixing the security concerns in the first release candidate, this is > the second release candidate for Apache Geode, version 1.4.0. > Thanks to all the community members for their contributions to this > release! > > *** Please download, test and vote by Thursday, Feb 1, 1400 hrs > US Pacific. *** > > It fixes 277 issues. release notes can be found at: > https://issues.apache.org/jira/secure/ReleaseNote.jspa? > projectId=12318420&version=12341842 > > Note that we are voting upon the source tags: rel/v1.4.0.RC2 > https://github.com/apache/geode/tree/rel/v1.4.0.RC2 > https://github.com/apache/geode-examples/tree/rel/v1.4.0.RC2 > > Commit ID: > 2a70679608120042fa7cbee67f4dd21a085d9588 (geode) > ced35f88173b04ac8e104b9cae10cc38289675fa (geode-examples) > > Source and binary files: > https://dist.apache.org/repos/dist/dev/geode/1.4.0.RC2 > > Maven staging repo: > https://repository.apache.org/content/repositories/orgapachegeode-1037 > > > Geode's KEYS file containing PGP keys we use to sign the release: > https://github.com/apache/geode/blob/develop/KEYS > > Release Signed with Key: pub 4096R/18F902DB 2016-04-07 > Fingerprint: E1B1 ABE3 4753 E7BA 8097 4285 8F8F 2BCC 18F9 02DB >
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/166
Geode unit tests 'develop/DistributedTest' took too long to execute
Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/108
