+1 for Geode functions as well. Back on the day, I've talked with Barry about it and we got a few basic ones into this repository.
https://github.com/markito/geode-functions But we should probably create another thread to talk about it to keep this one focused on the singletons discussion. On Thu, May 25, 2017 at 8:45 AM, Wes Williams <wwilli...@pivotal.io> wrote: > +1 to utility functions > > *Wes Williams | Pivotal Advisory **Data Engineer* > 781.606.0325 > http://pivotal.io/big-data/pivotal-gemfire > > On Wed, May 24, 2017 at 4:59 PM, John Blum <jb...@pivotal.io> wrote: > > > On a side but related note, it would be nice if Geode had the notion of > > useful, "canned" Functions provided OOTB. Some of the *Gfsh* functions > > would be quite useful for applications in fact, or particularly for > > framework/tools to use as well. Sometime ago I sent a list of Functions > I > > thought would be nice to have. > > > > Food for thought. > > > > On Wed, May 24, 2017 at 1:41 PM, Kirk Lund <kl...@apache.org> wrote: > > > > > Thanks for pointing out that DistributionManager is internal -- I > forgot > > > about that. I'm primarily concerned with internal Functions, such as > > those > > > for GFSH commands, so maybe an internal version of FunctionContext > which > > > exposes more would be good for those. > > > > > > On Wed, May 24, 2017 at 11:39 AM, Darrel Schneider < > > dschnei...@pivotal.io> > > > wrote: > > > > > > > FunctionContext is an external interface so it can not expose > internal > > > > interfaces like DistributionManager. > > > > But it could expose Cache. DistributedSystem is external so you could > > > have > > > > it exposed from FunctionContext but it is already exposed from Cache. > > > > SecurityService is also internal. > > > > Are you thinking that for internal Functions you would cast > > > FunctionContext > > > > to an internal that would then expose these internal classes? > > > > > > > > > > > > > > > > On Thu, May 18, 2017 at 5:13 PM, Kirk Lund <kl...@apache.org> wrote: > > > > > > > > > I've been digging through our code with close attention to the > > > > singletons. > > > > > I believe the majority of singletons in Geode exist for two main > > > reasons: > > > > > > > > > > 1) Insufficient context or lack of service lookup for Function, > > > > > DistributionMessage and (Client)Command implementations. > > > > > > > > > > 2) Poor OO design. This is where you see code in one class invoking > > > > > concrete methods on another class outside of its concerns. Many of > > > these > > > > > need to be teased apart and replaced with some sort of Observer > that > > > > > isolates the reaction from the source of the originating event. > > > > > > > > > > Right now my focus is on #1 because that's the area that's > currently > > an > > > > > obstacle for me. > > > > > > > > > > Function, DistributionMessage and (Client)Command classes need to > > have > > > > more > > > > > context provided to them (Cache, Security, etc) or they need a > better > > > > > mechanism to look up these services. Currently these classes reach > > out > > > to > > > > > singletons in order to "get" what they need. > > > > > > > > > > *A) Function* > > > > > > > > > > The main entry-point which injects services into the Function is: > > > > > > > > > > public void execute(FunctionContext<T> context); > > > > > > > > > > The FunctionContext needs to provide the service(s) that any > Function > > > > might > > > > > require. This could include Cache, DistributionManager and maybe > > > > > SecurityService (anything else?). > > > > > > > > > > *B) (Peer-to-peer) DistributionMessage* > > > > > > > > > > The main entry-point which injects services into the > > > DistributionMessage > > > > > is: > > > > > > > > > > protected abstract void process(DistributionManager dm); > > > > > > > > > > We could provide multiple arguments or a single new > > DistributionContext > > > > > which then provides DistributionManager and Cache (anything else?). > > > > > > > > > > *C) (Client) Command* > > > > > > > > > > The main entry-point which injects services into the Command is: > > > > > > > > > > public void execute(Message msg, ServerConnection servConn); > > > > > > > > > > ServerConnection is huge but it does already expose Cache. > > BaseCommand > > > is > > > > > the only Command that implements "execute" and it defines a new > > > > entry-point > > > > > for injection: > > > > > > > > > > abstract public void cmdExecute(Message msg, ServerConnection > > servConn, > > > > > long start) throws IOException, ClassNotFoundException, > > > > > InterruptedException; > > > > > > > > > > We might want to clean that up and define a new CommandContext > which > > > > > provides the Cache or anything else that the Command may need. > > > > > > > > > > Thoughts or additional ideas? > > > > > > > > > > > > > > > > > > > > -- > > -John > > john.blum10101 (skype) > > > -- ~/William
