January 2022 - logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1612) jul LevelChangePropagator is inconsistent with SLF4JBridgeHandler
by QOS.CH (JIRA) 16 Jan '22

16 Jan '22

1 0

[JIRA] Updates for LOGBACK-1612: jul LevelChangePropagator is inconsistent with SLF4JBridgeHandler
by QOS.CH (JIRA) 15 Jan '22

15 Jan '22

logback / LOGBACK-1612 [Open] jul LevelChangePropagator is inconsistent with SLF4JBridgeHandler ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1612 ============================== Issue created ------------------------------ Yonathan Randolph created this issue on 15/Jan/22 7:36 AM Summary: jul LevelChangePropagator is inconsistent with SLF4JBridgeHandler Issue Type: Bug Assignee: Logback dev list Components: logback-classic Created: 15/Jan/22 7:36 AM Environment: jre 1.8 jul-to-slf4j 1.7.26 (but [SLF4JBridgeHandler|https://github.com/qos-ch/slf4j/blob/v_1.7.33/jul-to-slf…] hasn't changed much as of 1.7.33) logback-classic 1.2.3 (but [JULHelper|https://github.com/qos-ch/logback/blob/v_1.8.0-alpha1/logback-cla…] hasn't changed much as of 1.8.0) Log messages are sent using java.util.logging. SLF4JBridgeHandler and LevelChangePropagator are enabled (I was running PlayFramework which does this automatically) logback.xml contains <logger name="com.sun.mail.util" level="DEBUG"/> Labels: logging Priority: Minor Reporter: Yonathan Randolph Description: LevelChangePropagator is inconsistent with jul-to-slf4j for intermediate values FINER, CONFIG, SEVERE, and any other custom jul Level that you construct. When you logger.finer(), it becomes DEBUG, but when you set the level to DEBUG, then logger.finer() messages disappear. When I configured the level for the logger com.sun.mail.util to ALL in my logback.xml, I observed log messages with level DEBUG. But when I configured the logger's level to DEBUG in logback.xml, the logger became disabled! The [library I was observing|https://github.com/eclipse-ee4j/angus-mail/blob/1.0.0/core/src/ma…] used java.util.logging and conditionally did {noformat} if (logger.isLoggable(Level.FINER)) logger.finer(""){noformat} h2. Current implementations jul-to-slf4j's [SLF4JBridgeHandler.callPlainSLF4JLogger|https://github.com/qos-ch/slf4j/blo…] given jul level _x_, it maps to a slf4j level _y_: * _x_ ≤ FINEST = 300 → TRACE * FINEST < _x_ ≤ FINE = 500 → DEBUG ** including FINER = 400 * FINE < _x_ ≤ INFO = 800 → INFO ** including CONFIG = 700 * INFO < _x_ ≤ WARNING = 900 → WARN * WARNING < _x_ → ERROR ** including SEVERE = 1000 -> TRACE LevelChangePropagator's [JULHelper.asJULLevel|https://github.com/qos-ch/logback/blob/v_1.8.0-alpha1/…] given slf4j level y, it maps to a jul level _x_. * slf4j TRACE → jul FINEST * DEBUG → FINE * INFO → INFO * WARN → WARNING * ERROR → SEVERE * OFF → OFF The problem is that these _x_ values are all at the top of the jul-to-slf4j intervals, but [java.util.logging.Logger.isLoggable|https://github.com/openjdk/jdk/blob/jdk…] will reject any message whose level is less than this _x_. So jul-to-slf4j will log a FINER message as DEBUG, but if you set the slf4j level to DEBUG, then FINER messages are rejected. h2. Proposed implementation: I think the correct behavior is for LevelChangePropagator to return the minimum value in each jul-to-slf4j interval rather than the maximum value, so that the values will be consistent * slf4j TRACE → jul Integer.MIN_VALUE * DEBUG → FINEST + 1 = 301 * INFO → FINE + 1 = 501 * WARN → INFO + 1 = 801 * ERROR → WARNING + 1 = 901 * OFF → OFF (this is special-cased in [java.util.logging.Logger.isLoggable|https://github.com/openjdk/jdk/blob/jdk…] ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for LOGBACK-1611: SocketAppender doesn't submit log messages sent right before the jvm exits
by QOS.CH (JIRA) 14 Jan '22

14 Jan '22

logback / LOGBACK-1611 [Open] SocketAppender doesn't submit log messages sent right before the jvm exits ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1611 ============================== Issue created ------------------------------ Mike M. created this issue on 14/Jan/22 1:37 PM Summary: SocketAppender doesn't submit log messages sent right before the jvm exits Issue Type: Bug Affects Versions: 1.2.9 Assignee: Logback dev list Components: logback-classic Created: 14/Jan/22 1:37 PM Priority: Major Reporter: Mike M. Description: We are in the process of migrating a big old project from Log4j1 to Logback. Since concepts and features are relatively close the migration itself worked pretty straight forward. Through our regression test suite, we noticed a change - actually a regression - in behavior in the following though: We have a {{ch.qos.logback.classic.net.SimpleSocketServer}} running to which a couple of other Java processes send log messages via {{ch.qos.logback.classic.net.SocketAppender}}s. I guess it's important to mention that these are pretty much plain Java Main processes, no Jetty or any other web- or application container, just plain Java processes. We found that in some cases, the last log messages logged right before the end of the main() method, so right before the JVM exits, aren't submitted to the server component. After reading through the docs, we added the {code:java} <shutdownHook class="ch.qos.logback.core.hook.DelayingShutdownHook"/>{code} (btw: the Doc is still broken, see LOGBACK-1090). The ShutdownHook closes the logging contet, which I would've expected to flush any pending log messages and finish transmitting them to the server. However, this doesn't seem to be the case because simply adding this hook didn't solve the problem. What did though was explicitly adding a delay before the context shutdown (I didn't find how to specify a delay in the documentation by the way - luckily, stack overflow came to the rescue). {code:java} <shutdownHook class="ch.qos.logback.core.hook.DelayingShutdownHook"> <delay>500</delay> </shutdownHook>{code} This finally made logback send out all messages before the VM exited. It seems like a flaky solution though since the required timing may vary based on various factors. It would be far better if logback's SocketAppender flushed and closed everything cleanly when the logging context closes. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] (LOGBACK-1610) Jetty 10 support
by QOS.CH (JIRA) 12 Jan '22

12 Jan '22

1 0

[JIRA] (LOGBACK-1610) Jetty 10 support
by QOS.CH (JIRA) 12 Jan '22

12 Jan '22

1 0

[JIRA] (LOGBACK-1610) Jetty 10 support
by QOS.CH (JIRA) 12 Jan '22

12 Jan '22

1 0

[JIRA] Updates for LOGBACK-1610: Jetty 10 support
by QOS.CH (JIRA) 12 Jan '22

12 Jan '22

logback / LOGBACK-1610 [Open] Jetty 10 support ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1610 ============================== Issue created ------------------------------ Scott Cantor created this issue on 12/Jan/22 6:02 PM Summary: Jetty 10 support Issue Type: Improvement Assignee: Logback dev list Components: logback-access Created: 12/Jan/22 6:02 PM Priority: Major Reporter: Scott Cantor Description: Is there any intent to try and make logback-access compatible with Jetty 10+? I was able to get something working relatively easily with a minor patch, though I did not pull in a number of changes that I guess Joakim had suggested. I saw some commits that would not work for 10 and 11 because they move everything to jakarta. There would need to be separate modules for 10/11 and 12 at a minimum (separately from the original that works on 9.4). I can provide the patch I used if it's helpful, but if the plan is to just stop supporting/tracking this, that would be good to know too. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] (LOGBACK-1554) Logback-access %b is empty, most of time
by QOS.CH (JIRA) 11 Jan '22

11 Jan '22

1 0

[JIRA] (LOGBACK-1575) Replace old servlet-api with jakarta servlet-api in logback-access
by QOS.CH (JIRA) 06 Jan '22

06 Jan '22

1 0

[JIRA] (LOGBACK-1575) Replace old servlet-api with jakarta servlet-api in logback-access
by QOS.CH (JIRA) 06 Jan '22

06 Jan '22

1 0