Injecting @ConfigProperty(name="quarkus.servlet.context-path") does not work in native mode

[jglick]

Describe the bug

@ConfigProperty works to inject quarkus.servlet.context-path into a field in JVM mode, but apparently not in native mode, or least not in tests.

Expected behavior

Behavior should be identical across @QuarkusTest and @SubstrateTest.

Actual behavior

Injection works as expected in JVM mode (surefire:test). Native tests (failsafe:integration-test) fail with Unable to start native image in 60s from NativeImageLauncher.waitForQuarkus after

Executing [/project/target/…-1.0-SNAPSHOT-runner, -Dquarkus.http.port=8091, -Dtest.url=http://localhost:8091, -Dquarkus.log.file.path=target/quarkus.log, -Dkubernetes.trust.certificates=true, -Dkubernetes.auth.tryServiceAccount=false, -Dkubernetes.master=http://localhost:39499/, -Dkubernetes.auth.tryKubeConfig=false, -Dkubernetes.namespace=test]
 javax.enterprise.inject.spi.DeploymentException: No config value of type [java.lang.String] exists for: quarkus.servlet.context-path
 	at io.quarkus.arc.runtime.ConfigRecorder.validateConfigProperties(ConfigRecorder.java:37)
 	at io.quarkus.deployment.steps.ConfigBuildStep$validateConfigProperties15.deploy_0(ConfigBuildStep$validateConfigProperties15.zig:120)
 	at io.quarkus.deployment.steps.ConfigBuildStep$validateConfigProperties15.deploy(ConfigBuildStep$validateConfigProperties15.zig:36)
 	at io.quarkus.runner.ApplicationImpl1.doStart(ApplicationImpl1.zig:147)
 	at io.quarkus.runtime.Application.start(Application.java:91)
 	at io.quarkus.runtime.Application.run(Application.java:204)
 	at io.quarkus.runner.GeneratedMain.main(GeneratedMain.zig:34)
 Exception in thread "main" java.lang.RuntimeException: Failed to start quarkus
 	at io.quarkus.runner.ApplicationImpl1.doStart(ApplicationImpl1.zig:191)
 	at io.quarkus.runtime.Application.start(Application.java:91)
 	at io.quarkus.runtime.Application.run(Application.java:204)
 	at io.quarkus.runner.GeneratedMain.main(GeneratedMain.zig:34)
 Caused by: javax.enterprise.inject.spi.DeploymentException: No config value of type [java.lang.String] exists for: quarkus.servlet.context-path
 	at io.quarkus.arc.runtime.ConfigRecorder.validateConfigProperties(ConfigRecorder.java:37)
 	at io.quarkus.deployment.steps.ConfigBuildStep$validateConfigProperties15.deploy_0(ConfigBuildStep$validateConfigProperties15.zig:120)
 	at io.quarkus.deployment.steps.ConfigBuildStep$validateConfigProperties15.deploy(ConfigBuildStep$validateConfigProperties15.zig:36)
 	at io.quarkus.runner.ApplicationImpl1.doStart(ApplicationImpl1.zig:147)
 	... 3 more

To Reproduce

Do not have a minimal public demo currently available. One resource had

@Inject KubernetesClient k8sClient;
@ConfigProperty(name = "quarkus.servlet.context-path") String contextPath;

Configuration

quarkus.http.port=8090
quarkus.http.test-port=8091
quarkus.servlet.context-path=/something

Screenshots

N/A

Environment (please complete the following information):

• Output of uname -a or ver: N/A (Dockerized environment)
• Output of java -version: N/A; using quay.io/quarkus/centos-quarkus-maven:19.2.0
• GraalVM version (if different from Java): ditto
• Quarkus version or git rev: 0.21.2

Additional context

Workaround: hardcode the context path in the source file, and rely on test coverage to catch mismatches with the actual value.

[machi1990]

I guess this is expected because ServletConfig is a build time config. Am I correct? @dmlloyd @gsmet

[gsmet]

Yes, probably, maybe we should make this config root BUILD_AND_RUN_TIME_FIXED instead.

@stuartwdouglas WDYT?

[dmlloyd]

Right, at present I believe that BUILD_TIME config root values are not stored in the run time image. However, perhaps that should change: even if the config objects themselves are not available at run time, there's probably no harm in making those properties available to those using the config API directly. The only cost would be the memory usage of the additional keys and values.

[machi1990]

Right, at present I believe that BUILD_TIME config root values are not stored in the run time image. However, perhaps that should change: even if the config objects themselves are not available at run time, there's probably no harm in making those properties available to those using the config API directly. The only cost would be the memory usage of the additional keys and values.

What will be the difference with BUILD_AND_RUN_TIME_FIXED ?

[dmlloyd]

Right, at present I believe that BUILD_TIME config root values are not stored in the run time image. However, perhaps that should change: even if the config objects themselves are not available at run time, there's probably no harm in making those properties available to those using the config API directly. The only cost would be the memory usage of the additional keys and values.

What will be the difference with BUILD_AND_RUN_TIME_FIXED ?

The difference would be that the configuration root classes and corresponding groups and objects would not exist in the run time image.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you!
We are doing this automatically to ensure out-of-date issues does not stay around indefinitely.
If you believe this issue is still relevant please put a comment on it on why and if it truly needs to stay request or add 'pinned' label.

[dmlloyd]

Relax, stalebot.

[johnpoth]

I ran into the same problem regarding application specific properties.

As a workaround I used the ConfigProvider.getConfig().getOptionalValue API which works in both @QuarkusTest and @SubstrateTest.

Thanks !