Substitutions don't honor latest value about config HOT 7 CLOSED

It's because the reference.conf is resolved by itself, the relevant spec text is:

The reference config for a given class loader should be merged and resolved first, and may be shared among all application configs in that class loader. Substitutions in the reference config are not affected by any application configs, because the reference config should be resolved by itself.

The application config should then be loaded, have the reference config added as a fallback, and have substitutions resolved. This means the application config can refer to the reference config in its substitutions.

from config.

This also tripped me up. Is there a way to get an unresolved reference config so I can merge them myself?

from config.

Sure you can always just use parseResources("reference.conf") and other building-block operations to replicate ConfigFactory.load(). The load methods are just a sort of canned, standard way to do things but you could do your own thing (with extra work).

from config.

For the record. This has bitten me as well.

from config.

I don't think there's much to do here that would be 1) backward compatible and 2) not just move the "gotcha" to a different scenario, but of course open to suggestions. It certainly is possible to construct your own way of doing things that works differently, using the library.

from config.

Fully agree: the current behavior allows sane sharing of defaultConfig(), which is a worthy goal.

For reference, here’s the solution developed in this thread: https://gist.github.com/4233706

from config.

If this is a common need and we want to "standardize" a solution such as dynamic.conf I'm certainly willing to discuss that feature request, but I guess I'll close this for now since I'm not familiar with the use case and don't have immediate action planned. The original report was describing the currently-designed behavior.

from config.