@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 <prhomb...@pivotal.io> wrote: > +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 configuration properties will be accessible via the (also > currently @Experimental) ClusterConfigurationService interface, accessible > via GfshCommand::getConfigurationService. > > On Thu, Mar 29, 2018 at 11:27 AM, Bruce Schuchardt <bschucha...@pivotal.io > > > wrote: > > > Yes, deprecate it. I think the few useful methods that John pointed to > > could be migrated to one of the other interfaces. Everything else > > primarily uses the DistributionManager for membership and messaging. > > > > > > On 3/29/18 10:37 AM, Jacob Barrett wrote: > > > >> 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 <gosulli...@apache.org> > >>> wrote: > >>> > >>> 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 > >>> why we shouldn't do this? > >>> > >>> Thanks, > >>> Galen > >>> > >> > > > -- -John john.blum10101 (skype)
