gnodet commented on code in PR #12694:
URL: https://github.com/apache/maven/pull/12694#discussion_r4357322348
##########
impl/maven-cli/src/main/java/org/apache/maven/cling/invoker/LookupInvoker.java:
##########
@@ -125,8 +127,10 @@ public final int invoke(InvokerRequest invokerRequest) {
Properties oldProps = new Properties();
oldProps.putAll(System.getProperties());
ClassLoader oldCL = Thread.currentThread().getContextClassLoader();
- // activateLogging() replaces them with SLF4JBridgeHandler, whose
classes live in Maven's realm
- Handler[] oldRootLoggerHandlers =
java.util.logging.Logger.getLogger("").getHandlers();
+ // activateLogging() replaces them with MavenJulHandler, whose classes
live in Maven's realm
Review Comment:
No, we should not. Unconditionally replacing JUL root handlers tramples on
the host's logging setup in embedded scenarios (IDE plugins, build servers with
custom `LogManager`). The guard should be:
```java
if (LogManager.getLogManager().getClass() == LogManager.class) {
// default LogManager — safe to install MavenJulHandler and set root
level
} else {
// custom LogManager (Log4j2-JUL bridge, container, etc.) — skip JUL
setup
// and skip ProjectBuildLogAppender's JUL capture path too
}
```
This matches `SLF4JBridgeHandler`'s own defense. I'll add this guard.
##########
impl/maven-core/src/main/java/org/apache/maven/internal/build/DefaultLogEvent.java:
##########
@@ -0,0 +1,81 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.internal.build;
+
+import java.time.Instant;
+
+import org.apache.maven.api.build.report.LogEvent;
+import org.apache.maven.api.build.report.LogLevel;
+
+/**
+ * Immutable implementation of {@link LogEvent}.
+ * <p>
+ * Public to allow construction from other packages within the Maven
+ * implementation (e.g. {@code ProjectBuildLogAppender}).
+ *
+ * @param timestamp when the event was produced
+ * @param level the severity level
+ * @param message the clean log message (without level prefix or ANSI)
+ * @param loggerName the name of the logger, or {@code null}
+ * @param stackTrace the stack trace string, or {@code null}
+ * @param formattedMessage the fully formatted console line, or {@code null}
+ * @param sourceClassName the source class name (Log API mojo FQCN or JUL
source), or {@code null}
+ * @param sourceMethodName the source method name (via StackWalker or JUL), or
{@code null}
+ * @param threadId the originating thread ID, or {@code -1} if
unavailable
+ * @param sequenceNumber the global sequence number for ordering, or {@code
-1} if unavailable
+ * @param projectId the project this event belongs to, or {@code null}
+ * @param mojoId the mojo execution that produced this event, or
{@code null}
+ */
+public record DefaultLogEvent(
Review Comment:
Yes, absolutely — capture it at event creation time. Reconstructing thread
name from `threadId()` after the fact is fragile: the thread may be gone,
pooled thread names rotate. `Thread.currentThread().getName()` at publish time
(in `ProjectBuildLogAppender` and `MavenJulHandler`) is cheap and
deterministic. Note that JUL's `LogRecord.getThreadID()` does not provide the
name, so we'd read it from `Thread.currentThread().getName()` at the point
`MavenJulHandler.publish()` is called.
I'll add `threadName()` as a field on `DefaultLogEvent` and populate it in
both capture paths.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
