Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

config_ordinal defined as property leaks into default properties #15221

Closed
renegrob opened this issue Feb 21, 2021 · 4 comments · Fixed by #15257
Closed

config_ordinal defined as property leaks into default properties #15221

renegrob opened this issue Feb 21, 2021 · 4 comments · Fixed by #15257
Labels
area/kotlin kind/bug Something isn't working
Milestone

Comments

@renegrob
Copy link
Contributor

renegrob commented Feb 21, 2021

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]

To Reproduce

1. Checkout the reproducer project

git clone https://github.com/renegrob/reproducer-base.git
git checkout config-ordinal

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

resources/application.yml

display:
  mach: 3
  unit:
    name: "mph"
    factor: 2.23694
quarkus:
  configuration:
    build-time-mismatch-at-runtime: fail
  package:
    type: fast-jar
  log:
    level: INFO

build/quarkus-app/config/application.yml

display:
  mach: 1
  unit:
    name: "km/h"
    factor: 1234.8
fix:
  value: THIS_SHOULD_NOT_BE_VISIBLE    

Environment (please complete the following information):

  • Output of uname -a or ver:
uname -a
Linux automatix 5.8.0-43-generic #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
  • Output of java -version:
java -version
openjdk version "11.0.10" 2021-01-19 LTS
OpenJDK Runtime Environment Zulu11.45+27-CA (build 11.0.10+9-LTS)
OpenJDK 64-Bit Server VM Zulu11.45+27-CA (build 11.0.10+9-LTS, mixed mode)
  • GraalVM version (if different from Java):
    N/A
  • Quarkus version or git rev:
    1.11.3.FINAL
  • Build tool (ie. output of mvnw --version or gradlew --version):
./gradlew --version

------------------------------------------------------------
Gradle 6.5.1
------------------------------------------------------------

Build time:   2020-06-30 06:32:47 UTC
Revision:     66bc713f7169626a7f0134bf452abde51550ea0a

Kotlin:       1.3.72
Groovy:       2.5.11
Ant:          Apache Ant(TM) version 1.10.7 compiled on September 1 2019
JVM:          11.0.10 (Azul Systems, Inc. 11.0.10+9-LTS)
OS:           Linux 5.8.0-43-generic amd64

Additional context
N/A

@renegrob renegrob added the kind/bug Something isn't working label Feb 21, 2021
@quarkus-bot
Copy link

quarkus-bot bot commented Feb 21, 2021

/cc @evanchooly

@renegrob
Copy link
Contributor Author

/cc @radcortez

@renegrob
Copy link
Contributor Author

I guess io.quarkus.deployment.configuration.BuildTimeConfigurationReader.ReadOperation line 382 is where the error happens.

@radcortez
Copy link
Member

Spec discussion: eclipse/microprofile-config#676

@quarkus-bot quarkus-bot bot added this to the 1.13 - master milestone Feb 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/kotlin kind/bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants