geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wes Williams <wwilli...@pivotal.io>
Subject Re: What to do with Singletons
Date Thu, 25 May 2017 13:45:01 GMT
+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 <jblum@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 <klund@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 <
> dschneider@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 <klund@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)
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message