Config prefix from extension refrence issues in YAML

[GregJohnStewart]

Describe the bug

In my extension, I have made configuration objects prefixed by "oqm.core.api", which seems to work fine as intended. In my consuming app, I use yaml. It seems that when using yaml, the structure is not setup as intended; instead of the expected:

oqm:
  core:
    api:
      # ...

I instead have to use:

oqm.core.api:
  # ...

This is despite the fact that Intellij linting seems to pick on the structured form in the provided hints (Intellij hints that the expected, object based setup should be what works).

When setting values using the expected form, an error along the lines of "the config root could not be found" occurs

Expected behavior

The configuration whould work as a nested object (the intuitive/ expected result), instead of the prefix itself as the root key.

Actual behavior

When setting values using the expected form, an error along the lines of "the config root could not be found" occurs

How to Reproduce?

Code locations:

• Code monorepo: https://github.com/Epic-Breakfast-Productions/OpenQuarterMaster/tree/dev
  (note the dev branch)
• Extension code: https://github.com/Epic-Breakfast-Productions/OpenQuarterMaster/tree/dev/software/libs/core-api-lib-quarkus
  • Configuration in question: https://github.com/Epic-Breakfast-Productions/OpenQuarterMaster/blob/dev/software/libs/core-api-lib-quarkus/runtime/src/main/java/tech/ebp/oqm/lib/core/api/quarkus/runtime/OqmCoreApiConfig.java
• Consuming app: https://github.com/Epic-Breakfast-Productions/OpenQuarterMaster/tree/dev/software/oqm-core-base-station
  • configuration exercising this issue is in the test application.yaml: https://github.com/Epic-Breakfast-Productions/OpenQuarterMaster/blob/dev/software/oqm-core-base-station/src/test/resources/application.yaml#L19

You can reproduce by ./mvnw install on the extension, then ./gradlew test on the consuming app.

Output of uname -a or ver

Linux oqm-dev 6.8.0-59-generic #61~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Apr 15 17:03:15 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

Output of java -version

openjdk version "21.0.6" 2025-01-21 OpenJDK Runtime Environment (build 21.0.6+7-Ubuntu-122.04.1) OpenJDK 64-Bit Server VM (build 21.0.6+7-Ubuntu-122.04.1, mixed mode, sharing)

Quarkus version or git rev

Both ext/app on 3.22.1

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

Extension: Apache Maven 3.6.3 / Consuming app Gradle: 8.5

Additional information

No response

[quarkus-bot]

/cc @radcortez (config)

[radcortez]

Hum, the error I've got is oqm.core.api.caching.oqmDatabase.refreshFrequencyEvery does not map to any root. This is because your build-time configuration and run-time configuration share the same prefix.

In this case, Quarkus tries to validate that all configurations are mapped. The oqm.core.api.caching.oqmDatabase.refreshFrequencyEvery is visible for build time, but it is only a runtime property. In fact, this is what shows that the configuration is working and how it should be set in application.yaml.

When you have such cases, you need to ignore the paths. You can do it within the extension runtime module:

public class OqmConfigBuilderCustomizer implements SmallRyeConfigBuilderCustomizer {
    @Override
    public void configBuilder(SmallRyeConfigBuilder builder) {
        builder.withMappingIgnore("oqm.core.api.**");
    }
}

And a registration via ServiceLoader in a META-INF/services/io.smallrye.config.SmallRyeConfigBuilderCustomizer.

[gsmet]

@radcortez I'm not sure I understand what you're saying. Aren't we using the same prefixes for runtime and build time config in core all the time?

[radcortez]

Yes, and we have an ignore for that case in our namespace:
https://github.com/quarkusio/quarkus/blob/main/core/runtime/src/main/java/io/quarkus/runtime/configuration/QuarkusConfigBuilderCustomizer.java#L138

The does not map to any root is a SmallRye Config feature to report unknowns, but in Quarkus this doesn't work due to how configuration can be split between build and runtime (and share the same sources). That is why we have a Quarkus-specific implementation for unknowns and extensions.

[gsmet]

Yeah so maybe our recommendations should be to use the quarkus.* namespace in extensions?

[GregJohnStewart]

Interesting, and thanks for looking into it!

I would argue against requiring/recommending quarkus.*, as not everyone's extension is meant to be part of the Quarkus(tm) ecosystem.

[radcortez]

Yes, we initially only supported quarkus as the namespace for configuration in extensions. We ended up changing it to allow any namespace since it gave users the impression that extensions outside the Quarkus ecosystem were also part of Quarkus.

I think we should be able to handle these cases automatically when we set up the config instances:
#47693

Right now, the easiest way is to add that manually as I described.