Shawn, 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. Thanks, ~Chris ----- Original Message ----- From: "Chris Pike" <[email protected]> To: [email protected] Sent: Wednesday, April 27, 2016 9:04:59 AM Subject: Re: Static Config Initialization Problems I agree it could be structured better, let me think about it. As for the GlobalIds, any variables being loaded from remote config can't be static since it could fail to load. ----- Original Message ----- From: "Shawn McKinney" <[email protected]> To: [email protected] Sent: Wednesday, April 27, 2016 8:36:48 AM Subject: Re: Static Config Initialization Problems > On Apr 26, 2016, at 6:33 PM, Chris Pike <[email protected]> wrote: > > Ok, I missed one of the spots where ldap connection calls the "remote" > config. Trying pulling and running the tests again. That did the trick, tests are passing now. I do have concerns about the local and remote config. I know why you did it, but don’t think that the caller should know which one it’s getting. Somehow we have to do that inside the config class itself. Any ideas? Also noticed that some references to GlobalIds uses getInstance() and some don’t. Is there some reason for that? Shawn
