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-
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
@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,
+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
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
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