I don't think we are just swapping grievances. The code has potentially fatal runtime errors with the static config blocks.
Let me ask this, can we assume that clients should always use the factories to communicate with the API? If yes, we could have all code call Config.getInstance() and have the factories make sure the remote config loaded before continuing. ----- Original Message ----- From: "Shawn McKinney" <[email protected]> To: [email protected] Sent: Monday, May 2, 2016 3:13:31 PM Subject: Re: Static Config Initialization Problems > On May 2, 2016, at 1:07 PM, Shawn McKinney <[email protected]> wrote: > > Now is prolly a good time to review the capabilities of the underlying > framework commons config: > https://commons.apache.org/proper/commons-configuration/userguide/user_guide.html > > I’ve got to think that this problem has already been solved. Anyway I’m > looking at the user guide now…. This section is interesting: https://commons.apache.org/proper/commons-configuration/userguide/howto_utilities.html#Wrapping_Configuration_Builders The problem with the new code is we’ve lost the encapsulation layer over the param source and that require’s caller to have knowledge. Keep in mind this is why I am using commons configuration. And this was the first class I worked on when I started this project. So I wholeheartedly agree that it best to use non-static configs but not at the expense of encapsulation. We’re just swapping grievances at that point. I told you in the beginning this was going to be tricky because this is the lynchpin for the entire system. Shawn
