[PROPOSAL] Deprecating DistributedSystem

2018-03-29 Thread Galen O'Sullivan
It looks like there are a few JIRA tasks open to deprecate methods on DistributedSystem, and it doesn't really have much functionality that would be useful to a user. I propose that we deprecate DistributedSystem itself, and keep the system management functionality internal. Is there any reason

Re: [PROPOSAL] Deprecating DistributedSystem

2018-03-29 Thread Jacob Barrett
Yes please!! On the C++ client we have completely stripped it of its utility as part of removing global. It is all but and internal class holding the SystemProperties bag and some other things that Cache can really own. -Jake > On Mar 29, 2018, at 10:16 AM, Galen O'Sullivan

Re: [PROPOSAL] Deprecating DistributedSystem

2018-03-29 Thread John Blum
Yes, framework and tooling. I see no reason why the functionality in o.a.g.distributed.DistributedSystem [1] should be hidden or internal. I would certainly remove the deprecated methods by now. A few other methods are questionable as to whether they really belong on the DistributedSystem

Re: [PROPOSAL] Deprecating DistributedSystem

2018-03-29 Thread John Blum
@Patrick - have a look at... http://gemfire-93-javadocs.docs.pivotal.io/org/apache/geode/cache/execute/FunctionService.html#onMember-org.apache.geode.distributed.DistributedMember- On Thu, Mar 29, 2018 at 2:23 PM, Patrick Rhomberg wrote: > +1 to deprecation. > > @John,

Re: [PROPOSAL] Deprecating DistributedSystem

2018-03-29 Thread Patrick Rhomberg
+1 to deprecation. @John, The context in which the findMember methods are useful is (as far as I can tell) limited to commands being run on a locator. These methods will remain accessible via the new public API in the (currently @Experimental) GfshCommand abstract class. Likewise, the

Re: [PROPOSAL] Deprecating DistributedSystem

2018-03-29 Thread Kirk Lund
We should probably consider moving ServerLauncher and LocatorLauncher from org.apache.geode.distributed to a different package (maybe org.apache.geode?). On Thu, Mar 29, 2018 at 10:32 AM, John Blum wrote: > Yes, framework and tooling. > > I see no reason why the functionality

Build failed in Jenkins: Geode-nightly #1148

2018-03-29 Thread Apache Jenkins Server
See Changes: [jdeppe] GEODE-4963: Ignore test for now [bschuchardt] GEODE-4969 PDX Type registry throws CacheClosedException causing random [bschuchardt] GEODE-4928 DistributedLockService doesn't work as

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

2018-03-29 Thread apachegeodeci
Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/238

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

2018-03-29 Thread Spring CI
--- Spring Data GemFire > Nightly-ApacheGeode > #871 was successful. --- Scheduled 2383 tests in total. https://build.spring.io/browse/SGF-NAG-871/ -- This

Re: [PROPOSAL] Deprecating DistributedSystem

2018-03-29 Thread John Blum
Correcting (for Geode) and adding to the o.a.g.cache.execute.FunctionService reference... http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/execute/FunctionService.html#onMember-org.apache.geode.distributed.DistributedMember-