JSON / YAML config reader

[jhalterman]

Create a separate module/dependency that can hydrate configuration objects (POJOs) from JSON / YAML configuration files.

[electrical]

I'm looking for a yaml config file reader for my own project but haven't found anything decent yet that i could use :-(

[jhalterman]

@electrical I was thinking of using Jackson, which has an optional data binder for YAML. Dropwizard uses Jackson for parsing YAML into POJO config objects:

https://github.com/dropwizard/dropwizard/blob/49ff92712a936554d2cf9bd7a2b09a0fc07eaf25/dropwizard-configuration/src/main/java/io/dropwizard/configuration/ConfigurationFactory.java#L86

[electrical]

Interesting :-) How would you access the variabels from the yaml file for example? Create a function for each setting or something else?

[jhalterman]

@electrical You can just use public fields instead of having getting/setter methods. Here's a config file that does that (ignore the annotations):

https://github.com/openstack/monasca-api/blob/master/java/src/main/java/monasca/api/ApiConfig.java

Here's a more stripped down example of using Jackson's YAML support to parse a file into an object:

https://github.com/openstack/monasca-common/blob/master/java/monasca-common-util/src/main/java/monasca/common/util/config/ConfigurationFactory.java

Usage would be something like:

MyConfig config = ConfigurationFactory.forClass(MyConfig.class).build(configFile);

[electrical]

I checked what Elasticsearch has done and they do something like this:

Integer shards = settings.getAsInt("index.number_of_shards", null);

First part is the setting name and second is the default value if the setting is not found. The getAsInt will force it into a certain type which can be handy.

[kuujo]

https://github.com/atomix/catalyst/blob/master/serializer/src/main/java/io/atomix/catalyst/util/PropertiesReader.java

We have that already, it just needs to be abstracted into an interface to support different types of configuration files.

On Mar 14, 2016, at 3:33 AM, Richard Pijnenburg [email protected] wrote:

I checked what Elasticsearch has done and they do something like this:

Integer shards = settings.getAsInt("index.number_of_shards", null);

First part is the setting name and second is the default value if the setting is not found. The getAsInt will force it into a certain type which can be handy.

— Reply to this email directly or view it on GitHub.

[electrical]

Perfect ;-)

[electrical]

Followup from my short chat with @jhalterman on Gitter some idea's i have how this could work.

Would be nice to split off the reading from a file ( properties / yaml / etc ) and the actual settings handling.

Dumping some idea's

Settings settings = settings.builder(); # Initialise settings constructor
settings.set('some.settings.name', 'value'); # Add a new string setting.
settings.set('some.settings.name', 'othervalue'); # Overwrite previous set value

String name = settings.getAsString('some.settings.name', 'default value'); # Get setting as a string and if it doesn't exist give back a default value


Settings node_settings = settings.group('some'); # Get only the settings for that key
String name = node_settings.getAsString('settings.name'); # Now we don't have to reference to that first key

Settings other_settings = settings.builder('/path/to/my/config.yam'); # Initialise settings builder and read from this file to populate the initial settings.

Settings internal_settings = settings.builder();
internal_settings.put(other_settings.group('node')); # Merge other_settings builder but only settings that start with 'node' with the new settings builder