Migrate from ConfigRoot to ConfigMapping in quarkus extensions with a custom config prefix

164 views Asked by At

Problem

We built our stack on top of quarkus and have several extensions with the @ConfigRoot class approach. We are now migrating to interfaces with @ConfigMapping as described in the Quarkus Extensions documentation.

We did all the configurations for our stack with a custom prefix (e.g. mystack.). We are now facing the problem that when using @ConfigMapping its not possible to use the same prefix for build and runtime configuration.

Having a shared prefix results in a config validation exception as the config loading mechanism validates that any configuration found can be mapped.

ERROR [io.qua.dep.dev.IsolatedDevModeMain] (main) Failed to start quarkus: io.smallrye.config.ConfigValidationException: Configuration validation failed:
        mystack.configKey does not map to any root

This is the intended behavior and is also described in the issue Extension config for both build and run time with same prefix #32674.

However, as many quarkus extensions share a prefix for build and runtime i've seen that sharing a configuration prefix is possible if it starts with quarkus. like quarkus.mystack. in our case.

Question

Is it possible to configure the config loading mechanism for the prefix mystack. with the same behavior as quarkus.?

If not - is splitting the runtime and buildtime config or moving to a prefix like quarkus.mystack. the only possible solution?

It seems like one of the key points for this behavior is the QuarkusConfigBuilderCustomizer (source link)

// Ignore unmapped quarkus properties, because properties in the same root may be split between build / runtime
builder.withMappingIgnore("quarkus.**");

Is there an easy way to add further prefixes to this list?

1

There are 1 answers

2
Roberto Cortez On BEST ANSWER

Yes, with the next Quarkus version (3.5.x), it is possible to register any number of SmallRyeConfigBuilderCustomizer to access the underlying Config builder and add additional mapping ignores for the custom prefix.

As a workaround, you can use quarkus.config.mapping.validate-unknown=false to disable the validation.