You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
If I have an application.properties file with an explicit priority config_ordinal=1000 it works well until I do a re-augmentation of the mutable-jar. It seems that during augmentation the config_ordinal value gets included in the default values which means that the priority of the default values all the sudden is the highest and they cannot be overwritten anymore. In my understanding the config_ordinal must be ignored when the current property values are included in the default properties.
We could work around it by defining a custom ConfigSource with ordinal = 1000 instead of setting the config_ordinal property. But that shouldn't be necessary.
I think it happens whenever a ConfigSource contains a config_ordinal value which is >= 100. One reason could be that you want a ConfigSource to have higher precedence than it usually would have. During augmentation the config_ordinal value is also included in the serialized default values and by that becomes the config_ordinal of the default value ConfigSource.
Expected behavior
If I set config_ordinal in a configuration file, it is only effective for the properties defined in that individual file.
Actual behavior
If I set config_ordinalin any configuration file that is read during augmentation then it affects other configuration sources. This is because the config_ordinal entry is afterwards also returned by the ConfigSource PropertiesConfigSource[source=Specified default values]
2. Build and start Quarkus with an external config file (build/quarkus-app/config/application.yml)
./gradlew clean build quarkusRun
3. The output shows the values of the config values:
2021-02-20 22:10:40,923 INFO [com.git.ren.con.StartupBean] (main) display.unit.name: mph
2021-02-20 22:10:40,924 INFO [com.git.ren.con.StartupBean] (main) fix.value: THIS_MUST_HAVE_PRIORITY
display.unit.name is set to "km/h" in the external config file. However because resources/application.properties contains config_ordinal=1000, all the properties defined in the project have the priority 1000.
If you comment out config_ordinal=1000 in resources/application.properties and do a rebuild (reaugmentation would be sufficient) then you see that display.unit.name is now correctly set to "km/h" but since config_ordinal=1000 is commented out, but it is now also possible to change the values defined in resources/application.properties. fix.value is now equal to "THIS_SHOULD_NOT_BE_VISIBLE".
4. Manual Fix
Patch build/quarkus-app/app/reproducer-base-1.0.0-SNAPSHOT.jar!application.properties and reactivate config_ordinal=1000 (e.g. with file-roller)
Don't rebuild or reaument!
Start Quarkus with ./gradlew quarkusRun
Now the output shows the expected values:
2021-02-20 22:27:13,310 INFO [com.git.ren.con.StartupBean] (main) display.unit.name: km/h
2021-02-20 22:27:13,311 INFO [com.git.ren.con.StartupBean] (main) fix.value: THIS_MUST_HAVE_PRIORITY
Note:
This only works if the app was augmented without config_ordinal
Configuration resources/application.properties
# This config_ordinal leaks into the default property values!config_ordinal=1000
fix.value=THIS_MUST_HAVE_PRIORITY
Describe the bug
If I have an application.properties file with an explicit priority config_ordinal=1000 it works well until I do a re-augmentation of the mutable-jar. It seems that during augmentation the config_ordinal value gets included in the default values which means that the priority of the default values all the sudden is the highest and they cannot be overwritten anymore. In my understanding the config_ordinal must be ignored when the current property values are included in the default properties.
We could work around it by defining a custom ConfigSource with ordinal = 1000 instead of setting the config_ordinal property. But that shouldn't be necessary.
I think it happens whenever a ConfigSource contains a config_ordinal value which is >= 100. One reason could be that you want a ConfigSource to have higher precedence than it usually would have. During augmentation the config_ordinal value is also included in the serialized default values and by that becomes the config_ordinal of the default value ConfigSource.
Expected behavior
If I set
config_ordinal
in a configuration file, it is only effective for the properties defined in that individual file.Actual behavior
If I set
config_ordinal
in any configuration file that is read during augmentation then it affects other configuration sources. This is because theconfig_ordinal
entry is afterwards also returned by the ConfigSourcePropertiesConfigSource[source=Specified default values]
To Reproduce
1. Checkout the reproducer project
2. Build and start Quarkus with an external config file (build/quarkus-app/config/application.yml)
3. The output shows the values of the config values:
display.unit.name
is set to "km/h" in the external config file. However becauseresources/application.properties
containsconfig_ordinal=1000
, all the properties defined in the project have the priority1000
.If you comment out
config_ordinal=1000
inresources/application.properties
and do a rebuild (reaugmentation would be sufficient) then you see thatdisplay.unit.name
is now correctly set to "km/h" but sinceconfig_ordinal=1000
is commented out, but it is now also possible to change the values defined inresources/application.properties
.fix.value
is now equal to "THIS_SHOULD_NOT_BE_VISIBLE".4. Manual Fix
2021-02-20 22:27:13,310 INFO [com.git.ren.con.StartupBean] (main) display.unit.name: km/h
2021-02-20 22:27:13,311 INFO [com.git.ren.con.StartupBean] (main) fix.value: THIS_MUST_HAVE_PRIORITY
Note:
This only works if the app was augmented without config_ordinal
Configuration
resources/application.properties
resources/application.yml
build/quarkus-app/config/application.yml
Environment (please complete the following information):
uname -a
orver
:java -version
:N/A
1.11.3.FINAL
mvnw --version
orgradlew --version
):Additional context
N/A
The text was updated successfully, but these errors were encountered: