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 <jb...@pivotal.io> wrote: > 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 interface, e.g. > releaseThreadsSockets(). > > However, many of these methods are very useful, e.g. > getDistributedMember(), > findDistriubtedMember(..), and especially getProperties(). > > In general, I don't really get the need to have any internal/hidden classes > in Geode and why most aspects of Geode should not be open and/or > extensible, i.e. "*Open for Extension; Closed for > Modification"... Open/Closed Principal [2]*). Most, if not all, APIs in > Geode should have an interface and a provider implementation that is > pluggable. I don't see why the DistributedSystem is any different. > > -j > > > [1] > http://geode.apache.org/releases/latest/javadoc/org/ > apache/geode/distributed/DistributedSystem.html > [2] https://en.wikipedia.org/wiki/Open/closed_principle > > > On Thu, 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) >
