prod properties get picked-up in dev profile

[alesj]

Describe the bug

When I build this project:

• https://github.com/alesj/drain-cleaner/tree/q1

Which has this application.properties

quarkus.http.port=8080

# SSL -> Production only
%prod.quarkus.http.ssl-port=8443
%prod.quarkus.http.ssl.certificate.file=/etc/webhook-certificates/tls.crt
%prod.quarkus.http.ssl.certificate.key-file=/etc/webhook-certificates/tls.key

# Logging
quarkus.log.level=INFO
#quarkus.log.category.okhttp3.level=WARN

And I run it via java -Dquarkus.profile=dev -jar target/quarkus-app/quarkus-run.jar
it looks like ssl properties are picked-up anyway ...

java -Dquarkus.profile=dev -jar target/quarkus-app/quarkus-run.jar
__  ____  __  _____   ___  __ ____  ______ 
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ 
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \   
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/   
2021-10-13 11:09:50,444 ERROR [io.qua.run.Application] (main) Failed to start application (with profile dev): java.nio.file.NoSuchFileException: /etc/webhook-certificates/tls.crt
	at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
	at java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:219)
	at java.base/java.nio.file.Files.newByteChannel(Files.java:370)
	at java.base/java.nio.file.Files.newByteChannel(Files.java:421)
	at java.base/java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:420)
	at java.base/java.nio.file.Files.newInputStream(Files.java:155)
	at io.quarkus.vertx.http.runtime.VertxHttpRecorder.getFileContent(VertxHttpRecorder.java:712)
	at io.quarkus.vertx.http.runtime.VertxHttpRecorder.createPemKeyCertOptions(VertxHttpRecorder.java:731)
	at io.quarkus.vertx.http.runtime.VertxHttpRecorder.createSslOptions(VertxHttpRecorder.java:633)
	at io.quarkus.vertx.http.runtime.VertxHttpRecorder.doServerStart(VertxHttpRecorder.java:482)
	at io.quarkus.vertx.http.runtime.VertxHttpRecorder.startServer(VertxHttpRecorder.java:254)
	at io.quarkus.deployment.steps.VertxHttpProcessor$openSocket-2064782366.deploy_0(VertxHttpProcessor$openSocket-2064782366.zig:146)
	at io.quarkus.deployment.steps.VertxHttpProcessor$openSocket-2064782366.deploy(VertxHttpProcessor$openSocket-2064782366.zig:40)
	at io.quarkus.runner.ApplicationImpl.doStart(ApplicationImpl.zig:622)
	at io.quarkus.runtime.Application.start(Application.java:101)
	at io.quarkus.runtime.ApplicationLifecycleManager.run(ApplicationLifecycleManager.java:101)
	at io.quarkus.runtime.Quarkus.run(Quarkus.java:67)
	at io.quarkus.runtime.Quarkus.run(Quarkus.java:41)
	at io.quarkus.runner.GeneratedMain.main(GeneratedMain.zig:30)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at io.quarkus.bootstrap.runner.QuarkusEntryPoint.doRun(QuarkusEntryPoint.java:53)
	at io.quarkus.bootstrap.runner.QuarkusEntryPoint.main(QuarkusEntryPoint.java:28)

Expected behavior

The ssl properties should be ignored.

Actual behavior

The ssl properties are used, despite dev profile.

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.4.0.CR1

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

No response

Additional information

No response

[geoand]

The weird thing is that using %prod.quarkus.http.port=... does take into account the value of -Dquarkus.profile.

@radcortez I think this is one for you.

[radcortez]

Ok, let me have a look.

[radcortez]

Ok, as I suspected, this is because when we build the application we use the prod profile and we record the values unprofiled in the default values source. Let me see if there is something we can do.

In the meanwhile, as a workaround emptying the values will work:

%dev.quarkus.http.ssl.certificate.file=
%dev.quarkus.http.ssl.certificate.key-file=