A fallback configuration supplies values that a higher-precedence configuration does not define. This avoids maintaining separate complete files for each environment: keep shared defaults in one configuration and override only deployment-specific values. section 7.1.4
Use the fallback structure to preserve predictable configuration behavior:
- Read a property from the highest-precedence configuration first; if it is absent there, resolve it from the fallback. section 7.3.1
- Prevent unset values from producing location-dependent behavior: requesting an unset property throws an exception rather than returning an empty value. section 7.1.4
- Place library defaults in reference.conf files at the root of JAR files so applications can inherit required settings automatically. section 7.1.4
- Chain configurations across Java properties, JSON, or HOCON files, and override properties with system properties when required. section 7.1.4
Override only the changed subtree
Suppose the fallback defines MyAppl.version = 10 and MyAppl.description = "My application". Lift subApplA into the higher-precedence configuration, where only description is changed to "Sub application". Then config.getString("MyAppl.description") returns "Sub application", while MyAppl.version falls through to the fallback and returns 10. Programmatically, the relationship is expressed as subApplACfg.withFallback(configuration). section 7.3.1
Figure 7.3 Priority of the configuration fallback structure. The highest priority is at the top and overrides definitions in lower files.
Use the priority diagram to inspect how higher configuration layers override definitions in lower fallback layers. section 7.1.4
