gnodet commented on code in PR #12694:
URL: https://github.com/apache/maven/pull/12694#discussion_r4357260190
##########
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:
Good catch. Currently the code unconditionally captures the root logger
handlers and level, then replaces them with `MavenJulHandler`. If the host JVM
has a custom `LogManager` (e.g. an embedded scenario where the parent
application uses Log4j2-JUL or a custom manager), we're trampling on it.
The right fix would be:
1. Check `LogManager.getLogManager().getClass() == LogManager.class` (i.e.
it's the default implementation) before touching any handlers/levels.
2. If a custom manager is detected, skip the JUL setup entirely and log a
debug message saying we're not installing MavenJulHandler because a custom
LogManager is active.
This matches what SLF4J's `SLF4JBridgeHandler` does — it bails early when it
can't safely manipulate the handler list.
I'll add this guard. The JUL-based log capture in `ProjectBuildLogAppender`
would also need to be skipped in that case, since events won't flow through
`MavenJulHandler`.
--
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]
