Move logging to @ConfigMapping

[radcortez]

• Partially Fixes Core module is using a mix of traditional @ConfigRoot and @ConfigMapping #42114

It would help to come up with fixes for:

• Confusing documentation or behaviour for quarkus.test.profile.tags #35693
• Logging configuration leaks from one test to the next #43180

Noticeable changes:

• The color hack in https://github.com/quarkusio/quarkus/pull/42157/files#diff-336136f742a05498477b4a3dd2b63bf198237f763c1a336ea654f3bc499e2c05L70-L80 is no longer required, since @ConfigMapping allows you to map the same configuration multiple times (the @ConfigRoot class implementation only allowed one matching property). So, quarkus.console.color is now available explicitly in both build time and runtime.
• The LogRuntimeConfig is also used during build time, but the @ConfigRoot limitation required the ConfigInstantiator to create it. Since LogBuildTimeConfig, LogRuntimeConfig, and ConsoleRuntimeConfig are required to set the build time and the runtime log, they are always registered by default, meaning they can be retrieved directly from SmallRyeConfig without any additional hacks
• Rewrote the pieces that set up the log categories because the code was mutating the configuration directly: https://github.com/quarkusio/quarkus/pull/42157/files#diff-4c8e61042dd080918dbcd9915ff27fda148515edc6359b7d580417deadba937cL318-L349. This is not possible anymore with @ConfigMapping.
• Same for log filters: https://github.com/quarkusio/quarkus/pull/42157/files#diff-3027189c5073a902729f033232338719972cd18a3c64018f24b99dd78e1fea6aL296-L304

[gsmet]

Thanks! Let's not merge this too quickly.

I wonder if 3.14 is the right version to merge this, or it would be better to wait for 3.16 to get branched.

For now, I implemented a workaround to support mixed extensions.

[radcortez]

Sure

[radcortez]

On a separate discussion, I wonder if we should introduce another config phase, BUILD_AND_RUN_TIME, which means values are read and used both on build and runtime. Probably only logging requires this, but maybe there are other use cases.

[geoand]

There is also a conflict in this

[gsmet]

Let's try to get this in for 3.16.

I rebased to get a fresh CI run.

@radcortez can you just have a look at my question?

[gsmet]

This was a mistake in the config file or something changed?

[radcortez]

I believe there is a mistake in the configuration file. The quarkus.log.file is a group:

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

Lines 51 to 52 in 3f8c3b3

	@ConfigDocSection
	public FileConfig file;

Also, there is no property with the parent's name.

[radcortez]

Sure. Thank you!

[gsmet]

I fixed an import conflict. Let's wait for CI and merge!

[radcortez]

Thanks!

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 9eff425.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

---

Flaky tests - Develocity

⚙️ JVM Tests - JDK 17

📦 extensions/opentelemetry/deployment

✖ io.quarkus.opentelemetry.deployment.metrics.HttpServerMetricsTest.collectsHttpRouteFromEndAttributes - History

• Assertion condition defined as a Lambda expression in io.quarkus.opentelemetry.deployment.common.exporter.InMemoryMetricExporter expected: <true> but was: <false> within 5 seconds. - org.awaitility.core.ConditionTimeoutException

org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a Lambda expression in io.quarkus.opentelemetry.deployment.common.exporter.InMemoryMetricExporter expected: <true> but was: <false> within 5 seconds.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
	at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:1006)
	at org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:790)
	at io.quarkus.opentelemetry.deployment.common.exporter.InMemoryMetricExporter.assertCountPointsAtLeast(InMemoryMetricExporter.java:131)
	at io.quarkus.opentelemetry.deployment.common.exporter.InMemoryMetricExporter_ClientProxy.assertCountPointsAtLeast(Unknown Source)

📦 extensions/smallrye-reactive-messaging/deployment

✖ io.quarkus.smallrye.reactivemessaging.hotreload.ConnectorChangeTest.testUpdatingConnector - History

• Expecting actual: ["-4","-5","-6","-7","-8","-9","-10","-11"] to start with: ["-3", "-4", "-5", "-6"] - java.lang.AssertionError

java.lang.AssertionError: 

Expecting actual:
  ["-4","-5","-6","-7","-8","-9","-10","-11"]
to start with:
  ["-3", "-4", "-5", "-6"]

	at io.quarkus.smallrye.reactivemessaging.hotreload.ConnectorChangeTest.testUpdatingConnector(ConnectorChangeTest.java:36)

• Expecting actual: ["-4","-5","-6","-7","-8","-9","-10","-11"] to start with: ["-3", "-4", "-5", "-6"] - java.lang.AssertionError

java.lang.AssertionError: 

Expecting actual:
  ["-4","-5","-6","-7","-8","-9","-10","-11"]
to start with:
  ["-3", "-4", "-5", "-6"]

	at io.quarkus.smallrye.reactivemessaging.hotreload.ConnectorChangeTest.testUpdatingConnector(ConnectorChangeTest.java:36)

• Expecting actual: ["-4","-5","-6","-7","-8","-9","-10","-11"] to start with: ["-3", "-4", "-5", "-6"] - java.lang.AssertionError

java.lang.AssertionError: 

Expecting actual:
  ["-4","-5","-6","-7","-8","-9","-10","-11"]
to start with:
  ["-3", "-4", "-5", "-6"]

	at io.quarkus.smallrye.reactivemessaging.hotreload.ConnectorChangeTest.testUpdatingConnector(ConnectorChangeTest.java:36)