geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Blum <jb...@pivotal.io>
Subject Re: What to do with Singletons
Date Wed, 24 May 2017 20:59:00 GMT
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