From dev-return-22570-apmail-geode-dev-archive=geode.apache.org@geode.apache.org Wed May 24 20:59:04 2017 Return-Path: X-Original-To: apmail-geode-dev-archive@minotaur.apache.org Delivered-To: apmail-geode-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id AAB191922D for ; Wed, 24 May 2017 20:59:04 +0000 (UTC) Received: (qmail 3147 invoked by uid 500); 24 May 2017 20:59:04 -0000 Delivered-To: apmail-geode-dev-archive@geode.apache.org Received: (qmail 3092 invoked by uid 500); 24 May 2017 20:59:04 -0000 Mailing-List: contact dev-help@geode.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@geode.apache.org Delivered-To: mailing list dev@geode.apache.org Received: (qmail 3079 invoked by uid 99); 24 May 2017 20:59:04 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 May 2017 20:59:04 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id A4D82CA9C3 for ; Wed, 24 May 2017 20:59:03 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.296 X-Spam-Level: X-Spam-Status: No, score=-0.296 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=pivotal-io.20150623.gappssmtp.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id dLXMEE7u-6no for ; Wed, 24 May 2017 20:59:02 +0000 (UTC) Received: from mail-pf0-f175.google.com (mail-pf0-f175.google.com [209.85.192.175]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id E31775F23E for ; Wed, 24 May 2017 20:59:01 +0000 (UTC) Received: by mail-pf0-f175.google.com with SMTP id e193so146701277pfh.0 for ; Wed, 24 May 2017 13:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pivotal-io.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=3gCxNcqcNq8Fq/Km1Ek//L/3cPRTF52n7G3fXwA5kvM=; b=DAPqKm9tI6tLygA8kqvOWwHY5wmBRO38kNCRdO1tGDDIe6CNqsF5FZ5SxGEr2e6q6I M8tZlgnY4YPBCd/NZPVN4AdI/71v82iXFQt6ghaVfseVuSkldu4d6H+j69kh7bzXWRn1 4gOYbK4GeGdR7J1nsCmlS95IaAPGL3koslvYrmkC9mbmHj3KpmBRcoo/gELXFTluUEH4 lnuK4ciLvnzy2g/WLMRXjvpTZfPkTY2kICme4kQ1gm4sy/gT6uP5NM0w2dKphVGhAoBC tslSsIPUiaASFjkpQyvM8MTJtBgcQKsaXheTQSiudJCZnsF7RpjK/PXtvbDIYlvyu0ai wnYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=3gCxNcqcNq8Fq/Km1Ek//L/3cPRTF52n7G3fXwA5kvM=; b=lCJ0jzCKUptcSC0zNptIEdmbcJzOLuyTWdyXnlxEXSwDHTI5Fp4D27lwg5hz7cirjC G8rzC4ZlA35HYo3NAYcDTXjdrr4GCBNU+QvD6fOovRmeMnZ5HiER6XirzczGTIB4TmN0 /w3OQLujTd5ybnEVZxfMfd2RbH6TAVcKYbFIOBP+nVoMNE7awvrg7F7xy/KAcJ1tgaIf Tx41vjn7ot5MmJ4hGOKvlOo77VMLOBwwEiUHzaHgCKuPTLTK009fYPiiPnP30nK6eDyM LapYGnelPNHqpXOGToZ5JMYendk9gmmiYsvppt1odpoEktMNTRbs2W40HBhzcSMGll3m QiHw== X-Gm-Message-State: AODbwcA8GC7pUAIN7LIl/R41x37J8bVSmiHW8ZJY8APkgX9ljbctb4/W M3Uu4unN1XBTq5myivEAGcC0vMkcL8G3 X-Received: by 10.84.238.195 with SMTP id l3mr46187699pln.102.1495659540646; Wed, 24 May 2017 13:59:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.158.100 with HTTP; Wed, 24 May 2017 13:59:00 -0700 (PDT) In-Reply-To: References: From: John Blum Date: Wed, 24 May 2017 13:59:00 -0700 Message-ID: Subject: Re: What to do with Singletons To: geode Content-Type: multipart/alternative; boundary="f403045fe49ca0232505504b5fe7" --f403045fe49ca0232505504b5fe7 Content-Type: text/plain; charset="UTF-8" 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 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 > 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 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 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) --f403045fe49ca0232505504b5fe7--