Re: [DISCUSS] changes to registerInterest API

I started work on the following plan: - deprecate current "ALL_KEYS" and List passing behavior in registerInterest () - add registerInterestForAllKeys(); - add registerInterest(T... keys) - add registerInterest(Iterablekeys) I might be missing something here but: With the addition of registerInter

Re: [DISCUSS] changes to registerInterest API

Does anyone actually do this in practice? If so, yikes! Even if the List is immutable, the elements may not be, so using a List as a key starts to open 1 up to a lot of problems. As others have pointed out in SO and other channels, information should not be kept in the key. It is perfect fine t

Re: [DISCUSS] changes to registerInterest API

For instance, this came up recently... https://stackoverflow.com/questions/46551278/gemfire-composite-key-pojo-as-gemfire-key I have seen other similar posts too! On Thu, Nov 30, 2017 at 2:30 PM, John Blum wrote: > Does anyone actually do this in practice? If so, yikes! > > Even if the List

please read: geode-3923

GEODE-3923 changes have been merged to develop life as you know it will change a bit.  The merge implements serialization white-listing/blacklisting and to insure that we have white-listed the correct set of classes, and that no new Geode classes are introduced that aren't properly registered,

Re: [DISCUSS] changes to registerInterest API

Yeah I am not sure if anyone does it,and I don't think it would be a good idea to use a collection as a key but just thought I'd ask the question... On Thu, Nov 30, 2017 at 2:33 PM John Blum wrote: > For instance, this came up recently... > > > https://stackoverflow.com/questions/46551278/gemfir

Re: [DISCUSS] changes to registerInterest API

No, no... good question. I just think it would be wiser if users created a single, CompositeKey class type, with properly implements equals and hashCode methods, as I pointed out. I don't see any advantage in using a java.util.Collection as a key over implementing a CompositeKey type. As such, a

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #752 was SUCCESSFUL (with 2264 tests). Change made by Oliver Gierke.

--- Spring Data GemFire > Nightly-ApacheGeode > #752 was successful. --- Scheduled with changes by Oliver Gierke. 2266 tests in total. https://build.spring.io/br

Re: [DISCUSS] changes to registerInterest API

I think it should be registerInterestAll(Iterablekeys) to mirror Collection.addAll. I could easily see a user creating their own Tuple class or using one that happens to also implement Iterable as their key. We're not doing a very good job of discouraging people to use iterable objects as their k

Build failed in Jenkins: Geode-nightly #1029

See Changes: [github] GEODE-3539: add ability to stop a vm without clean out the working dir [jiliao] GEODE-3788: add alter async-event-queue command and tests [github] GEODE-4000: The serializerClass is actually

Build failed in Jenkins: Geode-nightly-flaky #183

See Changes: [github] GEODE-3539: add ability to stop a vm without clean out the working dir [jiliao] GEODE-3788: add alter async-event-queue command and tests [github] GEODE-4000: The serializerClass is actu