[Main] SR Config 3.11 causes exception on startup

[manofthepeace]

Describe the bug

Was a bit worried about this update due to smallrye/smallrye-config#1264 . With it my app did break, but not where I actually expected it to break.

Where it break;

public class Feature1HttpConfigValidator implements ConstraintValidator<ValidFeature1HttpConfig, Feature1HttpConfig> {
    @Override
    public boolean isValid(Feature1HttpConfig feature1Config, ConstraintValidatorContext context) {
            ChannelConfig config = ConfigProvider.getConfig().unwrap(SmallRyeConfig.class)
              .getConfigMapping(AnotherConfig.class);
    }
}

causes; java.util.NoSuchElementException: SRCFG00027: Could not find a mapping for org.acme.config.AnotherConfig

Expected behavior

config should be there and work.

Actual behavior

exception is thrown

How to Reproduce?

reproducer

1- Application will start as is. (quarkus:dev)
2- Change quarkus version to 999-SNAPSHOT (one that includes sr config 3.11)
3- application will not start (quarkus:dev)

Output of uname -a or ver

Darwin Kernel Version 24.2.0

Output of java -version

openjdk version "21.0.5" 2024-10-15 LTS

Quarkus version or git rev

main

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

mvn 3.9.9

Additional information

No response

[quarkus-bot]

/cc @radcortez (config)

[manofthepeace]

I have added a reproducer in the OP

[gsmet]

TBH, I'm not entirely sure this is a supported use case but I will let @radcortez comment on this.

[manofthepeace]

Right, all I can say is that it worked since pretty much forever in my case. If it's not supported I'd appreciate a workaround when the validation needs to depend on the configvalue of another unrelated ConfigMapping (which cannot logically be part of the other)

[radcortez]

The Config validation was executed only at mapping retrieval because we had a circular dependency between Config and the Validator. We required the Config to create the Validator and late bind it, so we went with that approach, but that was not the original plan. The plan was to perform the validation when the mapping was populated. For instance, populating a mapping can generate a few errors (required, expression expansion, etc.). It didn't make much sense for the Validator validations to be executed at a different time (which could happen long after the runtime started).

When we added a standalone Config for the Validator in #32586, that limitation went away, but we never fixed the original behaviour, until now.

I would say that if there is a dependency in the validation, then the configuration should probably be part of the same tree, and that would work. The only option I see at the moment is to retrieve any configuration by its name (instead of the mapping).

I can try to think of some other options, but in reality, we never thought about this use case, and it only worked because of our own limitations :)

[manofthepeace]

It didn't make much sense for the Validator validations to be executed at a different time (which could happen long after the runtime started).

totally makes sense.

When we added a standalone Config for the Validator in #32586, that limitation went away, but we never fixed the original behaviour, until now.

interesting that fixes a bug from an older me.

The only option I see at the moment is to retrieve any configuration by its name (instead of the mapping).

ok yes that's what I thought.

I have a problem with the above though. my config mapping is like this;

@StaticInitSafe
@ConfigMapping(prefix = "conf")
public interface Config {

    @WithName("value")
    List<InnterMapping> value();

    interface InnerMapping {
        String key();

        List<String> id();
    }
}

when I do; List<InnerMapping> values = config.getValues("conf.value", InnerMapping.class);

I get
java.lang.IllegalArgumentException: SRCFG00013: No Converter registered for interface org.acme.Config$InnterMapping

can I make the getValues not try to run a converter, but use the sub interface of the mapping?

[manofthepeace]

Simplest I found is something like this;

        SmallRyeConfig config = ConfigProvider.getConfig().unwrap(SmallRyeConfig.class);
        Function<String, List<List<String>>> fetchValues = source -> {
            List<Integer> indices = config.getIndexedPropertiesIndexes(source);
            return indices.stream()
                    .map(i -> config.getValues(source + "[" + i + "].id", String.class))
                    .collect(Collectors.toList());
        };

[radcortez]

Here is another trick that you can use:

quarkus/core/runtime/src/main/java/io/quarkus/runtime/logging/LoggingSetupRecorder.java

Lines 91 to 119 in 8fe3c76

	SmallRyeConfig config = ConfigProvider.getConfig().unwrap(SmallRyeConfig.class);
	// There may be cases where a Config with the mappings is already available, but we can't be sure, so we wrap
	// the original Config and map the logging classes.
	SmallRyeConfig loggingConfig = new SmallRyeConfigBuilder()
	.withCustomizers(new QuarkusConfigBuilderCustomizer())
	.withMapping(LogBuildTimeConfig.class)
	.withMapping(LogRuntimeConfig.class)
	.withMapping(ConsoleRuntimeConfig.class)
	.withSources(new ConfigSource() {
	@Override
	public Set<String> getPropertyNames() {
	Set<String> properties = new HashSet<>();
	config.getPropertyNames().forEach(properties::add);
	return properties;
	}
	@Override
	public String getValue(final String propertyName) {
	return config.getRawValue(propertyName);
	}
	@Override
	public String getName() {
	return "Logging Config";
	}
	}).build();
	LogRuntimeConfig logRuntimeConfig = loggingConfig.getConfigMapping(LogRuntimeConfig.class);
	LogBuildTimeConfig logBuildTimeConfig = loggingConfig.getConfigMapping(LogBuildTimeConfig.class);
	ConsoleRuntimeConfig consoleRuntimeConfig = loggingConfig.getConfigMapping(ConsoleRuntimeConfig.class);

You just create a new instance of SmallRyeConfig, with a custom ConfigSource that delegates the relevant lookups to the current config.

[manofthepeace]

That's a neat trick. Thanks. So I think this is overall as designed, so let's close this issue.