Copilot commented on code in PR #8343:
URL: https://github.com/apache/hop/pull/8343#discussion_r3996754637
##########
ui/src/test/java/org/apache/hop/ui/hopgui/notifications/providers/NotificationHttpTest.java:
##########
@@ -135,4 +135,16 @@ public void testBoundedStreamCountsSingleByteReads()
throws Exception {
assertEquals(body.length, count);
}
}
+
+ @Test
+ public void testWireLoggingIsSuppressed() {
+ NotificationHttp.newClient();
+ java.util.logging.Logger wireLogger =
+ java.util.logging.Logger.getLogger("org.apache.hc.client5.http.wire");
+ assertEquals(java.util.logging.Level.INFO, wireLogger.getLevel());
+
+ org.slf4j.Logger slf4jWireLogger =
+ org.slf4j.LoggerFactory.getLogger("org.apache.hc.client5.http.wire");
+
org.junit.jupiter.api.Assertions.assertFalse(slf4jWireLogger.isDebugEnabled());
Review Comment:
This SLF4J assertion does not exercise the production backend in this
module: `hop-core` declares `slf4j-nop`, while `hop-ui` does not add the Log4j2
SLF4J binding. With the NOP provider, `isDebugEnabled()` is false regardless of
whether `Configurator.setLevel(...)` ran, so a regression in the actual
suppression path would still pass. Assert the Log4j2 logger directly or run
this test with the production SLF4J binding.
##########
ui/src/main/java/org/apache/hop/ui/hopgui/notifications/providers/NotificationHttp.java:
##########
@@ -30,6 +32,22 @@
/** Shared HTTP setup for the notification providers. */
final class NotificationHttp {
+ /**
+ * Retain a strong reference so LogManager does not garbage-collect the
configured log level.
+ * Suppresses verbose HTTP wire debugging from flooding console logs.
+ */
+ private static final Logger WIRE_LOGGER =
Logger.getLogger("org.apache.hc.client5.http.wire");
+
+ static {
+ WIRE_LOGGER.setLevel(Level.INFO);
+ try {
+ org.apache.logging.log4j.core.config.Configurator.setLevel(
+ "org.apache.hc.client5.http.wire",
org.apache.logging.log4j.Level.INFO);
+ } catch (Throwable ignored) {
Review Comment:
Catching `Throwable` here silently discards VM-level failures such as
`OutOfMemoryError` or `ThreadDeath`, as well as unrelated Log4j initialization
failures. The fallback only needs to handle an unavailable or incompatible
optional Log4j2 implementation, so catch the relevant linkage/class-loading
error instead.
--
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]
