-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for java.util.Map
to ConfigInstantiator
#23652
Conversation
@@ -209,6 +209,7 @@ LoggingSetupBuildItem setupLoggingRuntimeInit(LoggingSetupRecorder recorder, Log | |||
possibleSupplier, launchModeBuildItem.getLaunchMode()); | |||
LogConfig logConfig = new LogConfig(); | |||
ConfigInstantiator.handleObject(logConfig); | |||
logConfig.categories.clear(); // FIXME: workaround for duplicate handlers in CategoryConfiguredHandlerTest:42 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stuartwdouglas @geoand this where I need some help:
The call on the previous line will now also provide category config (as expected). This makes the test fail because it only expects one ConsoleHandler and one FileHandler, not two of each.
I must say I'm very confused why LogConfig
is recreated here (it's already fully available to this method via log
, e.g. it's passed to recorder.initializeLogging()
on line 206).
I also fail to understand how LoggingSetupRecorder.initializeBuildTimeLogging()
(called further down) was ever able to handle category config:
quarkus/core/runtime/src/main/java/io/quarkus/runtime/logging/LoggingSetupRecorder.java
Line 263 in 2b44967
for (Map.Entry<String, CategoryConfig> entry : categories.entrySet()) { |
I mean, before my change
Maps
weren't even evaluated/populated...?
I'm less than sure what's the right approach here. Is the test to be adjusted? But aren't duplicated handlers a problem indeed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you need to add a clearHandlers() call to io.quarkus.bootstrap.logging.QuarkusDelayedHandler#buildTimeComplete.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason why LogConfig is created here is because it is runtime config, and this is a build time method. It's kinda hacky, but we basically just use whatever the current config would be to initialize build time logging (just so we don't have to duplicate all logging config into a new build time config).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be honest, I can't say I know the reason either
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stuartwdouglas can you shed some light on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you need to add a clearHandlers() call to io.quarkus.bootstrap.logging.QuarkusDelayedHandler#buildTimeComplete.
Makes sense and it does work! Thanks!
The reason why LogConfig is created here is because it is runtime config, and this is a build time method. It's kinda hacky, but we basically just use whatever the current config would be to initialize build time logging (just so we don't have to duplicate all logging config into a new build time config).
Ok, so LogConfig log
passed to this method is not to be confused with LogConfig logConfig
?
core/runtime/src/main/java/io/quarkus/runtime/configuration/ConfigInstantiator.java
Show resolved
Hide resolved
return map; | ||
} | ||
var processedSegments = new HashSet<String>(); | ||
// infer the map keys from existing property names |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I'm extracting the segments/map keys from all present property names.
At this point I have no idea whether or not this covers env var flavors (e.g. QUARKUS_FOO
).
...jects/bootstrap/runner/src/main/java/io/quarkus/bootstrap/logging/QuarkusDelayedHandler.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, looks like I left my comments on pending.
...jects/bootstrap/runner/src/main/java/io/quarkus/bootstrap/logging/QuarkusDelayedHandler.java
Outdated
Show resolved
Hide resolved
@@ -209,6 +209,7 @@ LoggingSetupBuildItem setupLoggingRuntimeInit(LoggingSetupRecorder recorder, Log | |||
possibleSupplier, launchModeBuildItem.getLaunchMode()); | |||
LogConfig logConfig = new LogConfig(); | |||
ConfigInstantiator.handleObject(logConfig); | |||
logConfig.categories.clear(); // FIXME: workaround for duplicate handlers in CategoryConfiguredHandlerTest:42 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you need to add a clearHandlers() call to io.quarkus.bootstrap.logging.QuarkusDelayedHandler#buildTimeComplete.
@@ -209,6 +209,7 @@ LoggingSetupBuildItem setupLoggingRuntimeInit(LoggingSetupRecorder recorder, Log | |||
possibleSupplier, launchModeBuildItem.getLaunchMode()); | |||
LogConfig logConfig = new LogConfig(); | |||
ConfigInstantiator.handleObject(logConfig); | |||
logConfig.categories.clear(); // FIXME: workaround for duplicate handlers in CategoryConfiguredHandlerTest:42 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason why LogConfig is created here is because it is runtime config, and this is a build time method. It's kinda hacky, but we basically just use whatever the current config would be to initialize build time logging (just so we don't have to duplicate all logging config into a new build time config).
I'm adding the backport label because I kind of "advertised" to users that logging in Unit tests now works in 2.7 and it's unexpected that it won't pick up category config (before this PR). |
This workflow status is outdated as a new workflow run has been triggered. Failing Jobs - Building 5781722
Full information is available in the Build summary check run. Failures⚙️ JVM Tests - JDK 11 #- Failing: integration-tests/kotlin integration-tests/picocli-native integration-tests/scala
📦 integration-tests/kotlin✖
📦 integration-tests/picocli-native✖
📦 integration-tests/scala✖
⚙️ JVM Tests - JDK 11 Windows #- Failing: integration-tests/kotlin integration-tests/picocli-native integration-tests/scala
📦 integration-tests/kotlin✖
📦 integration-tests/picocli-native✖
📦 integration-tests/scala✖
⚙️ JVM Tests - JDK 17 #- Failing: integration-tests/kotlin integration-tests/picocli-native integration-tests/scala
📦 integration-tests/kotlin✖
📦 integration-tests/picocli-native✖
📦 integration-tests/scala✖
⚙️ Maven Tests - JDK 11 #- Failing: integration-tests/maven
📦 integration-tests/maven✖
✖
✖
✖
✖
✖
✖
✖
✖
✖
⚙️ Maven Tests - JDK 11 Windows #- Failing: integration-tests/maven
📦 integration-tests/maven✖
✖
✖
✖
✖
✖
✖
✖
✖
✖
|
I need to have a closer look at those test failures. I guess that |
@@ -207,6 +207,7 @@ public void addLoggingCloseTask(Runnable runnable) { | |||
|
|||
public synchronized void buildTimeComplete() { | |||
buildTimeLoggingActivated = false; | |||
runCloseTasks(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turns out that calling clearHandlers()
breaks a couple of tests that try to capture log output (see #23652 (comment)).
Just running the close tasks instead is the "middle ground" that seems to work for all tests. Let's see what CI has to say...
The main motivation is to pick up log category level config when running a simple unit test (see also latest enhancements to
BasicLoggingEnabler
: #23628).This is in draft mode for now because the following test fails with twice the number of handlers than expected:
https://github.com/quarkusio/quarkus/blob/main/core/test-extension/deployment/src/test/java/io/quarkus/logging/CategoryConfiguredHandlerTest.java#L41-L42
For that I added a quickfix which surely isn't going to be merged like this. I'll add a comment so we can discuss this specifically.