Motivation

It is common to "override" configured values from other sources such as the system properties or environment variables. Now that #55 is implemented, ConfigurationNodes can be dynamic and even represent multiple types ("10" can be both the string "10" and the number 10).

This used to exist until it was reverted in 285a2a5 due to a bad implementation that didn't combine different sources.

Proposal

Allow ConfigurationBuilder.source(ConfigurationSource) calls to be chained to add additional sources. Deserializers will then receive a merged configuration that combines all sources.

@Configuration
interface MyConfiguration {
  @Property("property")
  String property();
}

property = props

property: yaml

 // the first source is prioritized - this is what the original implementation did, but was it the right choice?
MyConfiguration configuration = Warp.builder(MyConfiguration.class)
    .source(props)
    .source(yaml)
    .build();

assert configuration.property().equals("props");

Implementation

Implement a composite ConfigurationNode that combines several nodes then use that when calling the configuration deserializer.