ConfigProvider.getConfig().getOptionalValue("..").get() does not work in JUnitExtension any more

[flyinfish]

Describe the bug

since 3.18 it is not possible any more to get config in a junit-extension

public class JUnitExtensionUsingConfig implements BeforeEachCallback, AfterEachCallback {

    @Override
    public void afterEach(ExtensionContext extensionContext) {  //FIXME this doesn't work
        Config config = ConfigProvider.getConfig();
        Optional<String> value = config.getOptionalValue("quarkus.http.root-path", String.class);
        value.get(); //exception here, no value set
    }

    @Override
    public void beforeEach(ExtensionContext extensionContext) {//FIXME this doesn't work
        Config config = ConfigProvider.getConfig();
        Optional<String> value = config.getOptionalValue("quarkus.http.root-path", String.class);
        value.get(); //exception here, no value set
    }
}
java.util.NoSuchElementException: No value present
        at java.base/java.util.Optional.get(Optional.java:143)
        at org.acme.JUnitExtensionUsingConfig.beforeEach(JUnitExtensionUsingConfig.java:24)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
        Suppressed: java.util.NoSuchElementException: No value present
                at java.base/java.util.Optional.get(Optional.java:143)
                at org.acme.JUnitExtensionUsingConfig.afterEach(JUnitExtensionUsingConfig.java:17)
                ... 2 more

Expected behavior

should work ConfigProvider.getConfig() or at least with ConfigProvider.getConfig(SomeWellDocumented.class.getClassLoader())

Actual behavior

fails with java.util.NoSuchElementException: No value present

How to Reproduce?

https://github.com/flyinfish/quarkus--configprovider-junitext
follow readme

Output of uname -a or ver

Linux C70C7391 5.15.167.4-microsoft-standard-WSL2 #1 SMP Tue Nov 5 00:21:55 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Output of java -version

openjdk 21.0.6 2025-01-21 LTS

Quarkus version or git rev

3.18.*

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

Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)

Additional information

No response

[quarkus-bot]

/cc @radcortez (config)

[geoand]

I tried with Quarkus main (and also including the latest SR Config) and the issue persists

[radcortez]

I believe it only worked by accident. For that to work, the Quarkus CL and Config were being leaked outside its own JUnit Extension, which caused all sorts of weird issues. With #42715, we made those boundaries clear, meaning that both Quarkus CL and the Quarkus Config instance are contained in the Quarkus JUnit Extension Context.

We still bootstrap a Config instance that can be accessed with available configuration (application.properties if it exists), but not custom Quarkus Application sources (for example, a custom implementation of ConfigSource sitting in the tested Quarkus App).

@holly-cummins is doing some work in #34681 (a BIG piece of work in this area) that should make this work again, but until then, we need to work with our current design.

My recommendation is to add the required configuration in an application.properties (in the test directory). Alternatively, use an abstract class / default interface with the JUnit lifecycle methods and have the test extend / implement it.

I know the issue may be frustrating, and the current solutions are not perfect either. As explained, this was causing a few more problematic issues (caused by our design), which is not easy to fix, as you can see with all the work in #34681.

[holly-cummins]

I'll try this with my branch and see where we are. @flyinfish, do you have a self-contained reproducer? If not, I can make one based on the code sample you've provided. This looks like something we should have a test for (albeit disabled at the moment!)

[radcortez]

Yes, here is the reproducer:
https://github.com/flyinfish/quarkus--configprovider-junitext

[flyinfish]

Alternatively, use an abstract class / default interface with the JUnit lifecycle methods and have the test extend / implement it.

we are working on moving out code out of the JUnitExtionsion into a plain interface @BeforeEach default void useConfig() {..}

[holly-cummins]

Thanks for the easy reproducer, @flyinfish. I confirm that it runs cleanly on my branch, with both mvn test and quarkus test. 🎉 💪

So that's the good news, the bad news is that my branch has 385 TODOs in it, and I regressed a few tests last week which I need to sort out.