Loading properties from the environment and from properties files

[borisuu]

The Problem

While going through the samples, I noticed in the sample-03 that custom keys with uppercase letters custom.Key, custom keys in pascal case customKey and custom keys in snake case custom_key, are not loaded. Inspecting the Connector code I was able to find the location where this behaviour is introduced. The connector.spi.common.core-spi.main.ConfigImpl class converts all values to lower case and also replaces underscores with a dot. The ConfigImpl class is called from the connector.core.common.boot.main.DefaultServiceExtensionContext.

Suggested solutions

The easiest fix would be to make this the official behaviour and add documentation about this behaviour. The examples I suggest are:

# in .properties file -> Java code
config.key -> config.key
config.KEY -> config.key
config.Key -> config.key
config_key -> config.key
CONFIG_KEY -> config.key
configKey -> configkey

Alternatively if we want to support more flexible options, such as environment variables with subkeys, e.g. NAMESPACE__KEY_VALUE -> namespace.key_value we would have to introduce a separate EnvironmentConfigImpl to handle environment variables and a PropertiesConfigImpl which can handle properties files. The benefit of this approach is that we would not deviate too much from the default Java properties file behaviour which indeed allows users to use any name for the keys. Using this would allow the following:

# in .properties files -> in Java code
config.key -> config.key
config.KEY -> config.KEY
config.Key -> config.Key
config_key -> config_key
CONFIG_KEY -> CONFIG_KEY
configKey -> configKey

# in environment -> in Java code
CONFIG_KEY -> config_key
CONFIG__KEY -> config.key

I'm prepared to create a PR with a solution.

[ndr-brt]

I agree that there's a little misalignment on how the settings are read, in fact the "lowercase and replace undescores with dots" logic that currently is in the ConfigImpl would stay better in a specific ConfigFactory method that builds configuration from environment variables.
This way the settings would be considered as case-sensitive, fixing the main issue.

Though...

CONFIG__KEY -> config.key

this will be a breaking change, I know a lot of teams that are relying on that behavior. I would avoid such a change in the EDC core, also because I'm not aware about setting keys that contain the underscore.

To achieve that you could write your own custom ConfigurationExtension.

[borisuu]

You're right, the CONFIG__KEY -> config.key resolution would be a breaking change. Didn't actually think about the impact on existing projects.

[borisuu]

I'll make a PR with the commented changes and add an example for the ConfigurationExtension for the CONFIG__KEY -> config.key variant.