hi <@U12AGS8JG> - running into an interesting situ...

# hoplite

[Peter]

hi @sam - running into an interesting situation, is this the expected behaviour?

[Peter]

given

redis {
  host = ${MY_REDIS_HOST}
  port = ${MY_REDIS_PORT}
}

[Peter]

if the following is in the environment:

[Peter]

MY_REDIS_PORT=6378
redis.port=6379

[Peter]

using

data class RedisConfig(host: String, port: Int)

i’ll end up with RedisConfig("..", 6379)

[Peter]

i was expecting to end up with RedisConfig("..", 6378)

[sam]

that's an interesting one

[sam]

it's because it's using the env as a property source (for all values)

[sam]

I guess the preprocessor one should override it

[sam]

hmm it's tricky to fix

[sam]

the env var property source like "overlays" on the files

[sam]

you could disable that

[Peter]

i have no idea why redis.port in the environment is taking precedence over MY_REDIS_PORT in the environment if i specified MY_REDIS_PORT in my HOCON config file?

[sam]

because the env vars form like a "hidden" file

[sam]

that's applied over the top

[Peter]

by why does redis.port even apply to set the value in HOCON? i know that syntax is supported for reading values from the parsed HOCON configuration

[sam]

its not related to hocon

[sam]

you have an env var called 'redis.port' right

[Peter]

right

[sam]

so that forms a "file" which is like { redis { port : 1234 } }

[sam]

which then is the first match when the decoder says "give me a value for redis.port"

[Peter]

ahhh

[sam]

if I'm right, it's not even getting to your hocon file, and therefore the hocon override, because it's already present in the env

[sam]

The EnvironmentVariablesPropertySource, SystemPropertiesPropertySource and UserSettingsPropertySource sources are automatically registered, with precedence in that order

[sam]

EnvironmentVariablesPropertySource
The EnvironmentVariablesPropertySource reads config from environment variables. It does not map cases so HOSTNAME does not provide a value for a field with the name hostname.
For nested config, use a period to seperate keys, for example topic.name would override name located in a topic parent. Alternatively, in some environments a . is not supported in ENV names, so you can also use double underscore __. Eg topic__name would override name in a Topic object.
Optionally you can also create a EnvironmentVariablesPropertySource with allowUppercaseNames set to true to allows for uppercase-only names.

[sam]

what you can do is create your config loader without the default sources, then it won't use that EnvironmentVariablesPropertySource

[sam]

withDefaultSources(false) on the builder

[Peter]

will it still substitute host = ${MY_REDIS_HOST}?

[Peter]

with the value of MY_REDIS_HOST

[sam]

yes because that is an override that is applied by the envvar preprocessor

[sam]

so its another path

[sam]

now I think about it the EnvironmentVariablesPropertySource might not make a ton of sense

[sam]

it's just useful if you want to set ENV vars without putting them in files

[Peter]

gotcha - i understand now

[sam]

like you could do redis.port an env

[sam]

and you wouldn't need to put it in the hocon at all

[sam]

which is exactly how you found this to start with

[Peter]

EnvironmentVariablesPropertySource vs EnvVarPreprocessor … i missed the distinction there initially 😅

[sam]

hope that helps

[Peter]

thanks much!