RelocateConfigSourceInterceptor can not be tested using QuarkusTestProfile's getConfigOverrides()

[rteabeault]

Describe the bug

We have implemented a RelocateConfigSourceInterceptor that takes some properties and renames them to quarkus defined properties. For example,

lodestar.tenant.t2.datasource.jdbc.url gets relocated to quarkus.datasource.t2.jdbc.url.

If you are wondering why the reason is that we are using a yaml based config file and we would like to group all tenant specific properties together. So in this case we want all config for t2 to be under the t2 key.

When writing tests for this I used a QuarkusTestProfile and set configuration using getConfigOverrides(). I could see that the interceptor was firing and the keys were getting correctly mapped. However, when injecting the config objects such as DataSourcesBuildTimeConfig, DataSourcesRuntimeConfig, and DataSourcesJdbcRuntimeConfig into the test to check assertions you can see that they contain the t2 datasource. However, none of the child configuration such as username, password, or jdbc.url is set.

However, using QuarkusTestProfile.getConfigProfile() and an actual application.properties files does work.

Expected behavior

I would expect to be able to use QuarkusTestProfile.getConfigOverrides() to work with a RelocateConfigSourceInterceptor.

Actual behavior

Properties set in QuarkusTestProfile.getConfigOverrides() do seem to run through the interceptor. However, their values are not set on inspection.

How to Reproduce?

Reproducer here: https://github.com/rteabeault/config-testing

See LodestarTenantConfigSourceInterceptorTest.

Output of uname -a or ver

Darwin ANX4V0G0Q9P 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000 arm64

Output of java -version

openjdk version "21.0.1" 2023-10-17 LTS OpenJDK Runtime Environment Zulu21.30+15-CA (build 21.0.1+12-LTS) OpenJDK 64-Bit Server VM Zulu21.30+15-CA (build 21.0.1+12-LTS, mixed mode, sharing)

Quarkus version or git rev

3.12.1

Build tool (ie. output of mvnw --version or gradlew --version)

------------------------------------------------------------ Gradle 8.6 ------------------------------------------------------------ Build time: 2024-02-02 16:47:16 UTC Revision: d55c486870a0dc6f6278f53d21381396d0741c6e Kotlin: 1.9.20 Groovy: 3.0.17 Ant: Apache Ant(TM) version 1.10.13 compiled on January 4 2023 JVM: 21.0.1 (Azul Systems, Inc. 21.0.1+12-LTS) OS: Mac OS X 14.5 aarch64

Additional information

No response

[quarkus-bot]

/cc @geoand (kotlin), @radcortez (config)

[radcortez]

For this case, you also need a fallback interceptor.

The relocate will only apply a rule where if there is a relocation, look at the relocated name first and then look up the original name. So if there is a relocate from lodestar.tenant.t2.datasource.username to quarkus.datasource.t2.username consider:

lodestar.tenant.t2.datasource.username=sarah

A lookup to lodestar.tenant.t2.datasource.username returns sarah, and a lookup to quarkus.datasource.t2.username returns no value.

lodestar.tenant.t2.datasource.username=sarah
quarkus.datasource.t2.username=john

A lookup to lodestar.tenant.t2.datasource.username returns john due to the relocate, and a lookup to quarkus.datasource.t2.username returns john.

Because you have values that are only present in the lodestar.tenant namepace, and Quarkus looks the datasource configuration in its namespace, you need to provide a bidirectional lookup from quarkus to lodestar.tenant. So if there is a relocate from lodestar.tenant.t2.datasource.username to quarkus.datasource.t2.username and a fallback from quarkus.datasource.t2.username to lodestar.tenant.t2.datasource.username:

lodestar.tenant.t2.datasource.username=sarah

A lookup to lodestar.tenant.t2.datasource.username returns sarah, and a lookup to quarkus.datasource.t2.username returns sarah.

On another note, it works using the file approach because of the Quarkus configuration recording. During build time, Quarkus looks into every configuration name and records it with the relocated name. This only works for configuration sources available at build time, so other runtime sources also require the bidirectional lookup between relocate / fallback.