I was doing something similar to that for some other projects and found that cfg4j [1] to be a very clean and good framework to keep the format of the configuration generic and dynamic. Built-in support for Yaml and property files and can also ready from multiple sources like Git, Consul, classpath or filesystem obviously, including merge of configuration files.
We actually started with Apache Commons [2] but decided to go cfg4j because the API was a bit more clean, but both of them simplified a lot our configuration efforts. Just my 0.02c [1] cfg4j.org/releases/latest/#tutorial [2] https://commons.apache.org/proper/commons-configuration/ On Thu, Oct 5, 2017 at 3:34 PM, Mark Hanson <mhan...@pivotal.io> wrote: > One thing also to consider if you modifying the config structure, is an > evented config structure, so that registrants get callbacks if changes are > made that are real-time. > > Thanks, > Mark > > On Oct 5, 2017, at 12:49 PM, Galen O'Sullivan <gosulli...@pivotal.io> > wrote: > > > > I don't care too much about exactly what the configuration looks like, > but > > I want it to be unified, and I want it to be set when the cache starts. > > Checking system properties throughout the codebase whenever we feel like > is > > a bit too magic for me. > > > > In addition, it seems that in order to add a new value to > > DistributionConfig, I have to add it in several places. Config should be > in > > one place. Descriptions, values, ranges should be defined in one place > and > > Ideally it should be extendable, and it should have some checks to make > it > > hard to shoot yourself in the foot. > > > > For this particular problem, it turns out that we should not make it > > configurable via a property, but should get this information from > > SecurityService. I think that a unified config solution is something we > > should look into for the future, though. > > > > -Galen > > -- ~/William