Open BernardMarshall opened 3 years ago
Another way of doing it is using orElse combinator in ConfigSource.
descriptor[MyConfig] from source1.orElse(source2)
Thanks for the reply. Yes that is possible. It just means moving the ${?app.config} markers out of the Hocon file and into a config descriptor so that the system properties can be used. Not a big deal, but it is nice to have the markers in the Hocon file as it "documents" how a config property can be set.
Sure.we will definitely see if we can fix this issue. Meanwhile, generateDocs(descriptor).toTable.asGithubFlavouredMarkdown can give us a doc and a list of sources associated with each parameter. See if it’s of any help
On Fri, 27 Nov 2020 at 10:04 AM, Bernard Marshall notifications@github.com wrote:
Thanks for the reply. Yes that is possible. It just means moving the ${?app.config} markers out of the Hocon file and into a config descriptor so that the system properties can be used. Not a big deal, but it is nice to have the markers in the Hocon file as it "documents" how a config property can be set.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/zio/zio-config/issues/419#issuecomment-734502800, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABY2QJJWHWPG3G3XBPPBO2LSR3NGZANCNFSM4SQPQB5Q .
The parsing of the Hocon files and strings use the
ConfigFactory.parseFile
andConfigFactory.parseString
methods. Both these methods load the configuration but do not include the system properties. Hence if you have substitutions of the form${?app.config}
in your Hocon file/string then the substitution is not resolved if the value is set in the system properties. To have the system properties loaded a call toConfigFactory.defaultOverrides
is required.A possible fix (in TypesafeConfigSource.scala) is to change:
to be:
A similar change could be added to the
fromHoconString
method. The change ensures system properties are resolved correctly in Hocon files/strings.