Description

Multiple irritations concerning the Configuration Form Editor in Dev UI, when we edit properties - and the editor stores the changes into the application.properties. TL;DR: I would suggest to disable re-writing properties changes to the application.properties file.

Encoding

SmallRye Config loads the application.properties with this code:

try (BufferedReader reader = new BufferedReader(new InputStreamReader(inputStream, UTF_8))) {
    properties.load(reader); 
}

(Source)

Quarkus' ConfigurationProcessor uses

Files.readAllLines(configPath)

In case of ISO-8859-1 encoded application.properties files, the first one works (except for some characters that are decoded to invalid chars), the second one throws an exception.

Environment Variables

As described in the MicroProfile Config spec, properties are resolved from multiple config sources with a given priority. E.g. environment variables overwrite values in the application.properties. Changing the values in the Dev UI and writing them into the application.properties won't work because they are still shadowed by the environment variables. Much worse: This changes the convention for environments that do not have such an environment variable!

Profiles

Same with profiles. If we have a %dev.<name>=<value> property, it is re-written as <name>=<value>, which won't work for dev profile, but change default values for all other profiles!

Formatting

If we use space chars in application.properties(variable = value), then the entry will occur twice, because it is not found when re-writing the values.

Maven Resource Filtering

If we use Maven resource filtering to replace ${} expressions by Maven properties, the resolved values are shown in the Dev UI. If we change them, we will replace the ${} expression in the source. This is because of another difference between SmallRye Config and the ConfigurationProcessor: SmallRye loads from target/classes/application.properties, whereas the ConfigurationProcessor writes to src/main/resources/application.properties.

Hot Replacement

Of course, properties are loaded and injected only at startup, changes during runtime won't be processed by the components. For continuous testing, this might be helpful, so we could provide a CDI-event-based approach in the Dev UI, but this won't work for all properties. (and the developer should be aware of that - this might be unclear when providing an editor that allows changing values at runtime)

Implementation ideas

Because of all these confusing points, I'm not sure what added value the editor has (except for single cases like continuous testing). I would suggest to

• disable rewriting changes to application.properties (this could be done by the developer manually)
• allow changes only for some properties (maybe those properties can be registered to be editable) and fire CDI events in case of changes

Of course, I could make a PR for this, but first I need the discussion about that.