> On May 2, 2016, at 9:48 AM, Shawn McKinney <[email protected]> wrote: > >> >> On May 2, 2016, at 9:32 AM, Chris Pike <[email protected]> wrote: >> >> Currently, calling Config will give you both local and remote config, so the >> only code calling LocalConfig is code loading properties needed for setting >> up the connection. I'm not sure if there is a great way to abstract it any >> further. Potentially, we could create a RemoteConfig class and let Config be >> the common interface to both. But it would have to keep state on whether >> remote config was loaded, and then try to load it every time any of the >> getProperty methods was called until successful. >> >> As for the GlobalIds, it might make sense to make all the non static calls >> just method in the Config class and not make GlobalIds a singleton. >> >> I built a VM with this branch, and it passed all the unit tests, I ran a >> bunch of the JMeter tests as well, but not sure what is considered >> acceptable performance. > > Chris agree with the making all calls to globalids use the nonstatic call.
Actually I misspoke here. Why not make all calls to globalids like this: GlobalIds.getInstance().WHATEVER? It’s ugly but consistent. We can figure out a better abstraction later.
