- logback-dev - mailman3.qos.ch

multiple appender-refs in <root> : unexpected behaviour ?
by logback developers list 23 Apr '25

23 Apr '25

Using logback-classic in Maven: <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>1.5.18</version> <scope>runtime</scope> </dependency> If one <root> appender-ref is defined (STDOUT) but another is undefined (CLOUD_LOGGING): <root level="info"> <appender-ref ref="STDOUT" /> <appender-ref ref="CLOUD_LOGGING" /> </root> logback fails to set the defined appender in <root>. In main() after server.start()I see WARN in Logger[org.eclipse.jetty.server.Server] - No appenders present in context [default] for logger [org.eclipse.jetty.server.Server]. Is this expected behaviour ? Would be better if it selected whichever is defined.

1 0

Print literal curly bracket
by logback developers list 18 Feb '25

18 Feb '25

Hi How to print the curly bracket } in the SuffixPattern of ch.qos.logback.classic.net.SyslogAppender? I tried escaping with backslash, HTML-encoding but without success. Use case: My %msg has a JSON format, but I need to add some fields via MDC and then close the JSON message with a curly closing bracket. Kind regards, Philip

1 0

[JIRA] (LOGBACK-1496) Add support for overriding default LogbackMDCAdapter
by logback developers list 03 Feb '25

03 Feb '25

1 0

[JIRA] (LOGBACK-1406) Seems all threads blocked
by logback developers list 01 Nov '24

01 Nov '24

1 0

[JIRA] (LOGBACK-1406) Seems all threads blocked
by logback developers list 01 Nov '24

01 Nov '24

1 0

[JIRA] (LOGBACK-1776) SizeAndTimeBasedRollingPolicy does not take into account the initial size of an existing log file
by logback developers list 25 Oct '24

25 Oct '24

1 0

[JIRA] Updates for LOGBACK-1776: SizeAndTimeBasedRollingPolicy does not take into account the initial size of an existing log file
by logback developers list 25 Oct '24

25 Oct '24

logback / LOGBACK-1776 [Open] SizeAndTimeBasedRollingPolicy does not take into account the initial size of an existing log file ============================== 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-1776 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 25/Oct/24 15:25 Summary: SizeAndTimeBasedRollingPolicy does not take into account the initial size of an existing log file Issue Type: Bug Assignee: Logback dev list Created: 25/Oct/24 15:25 Environment: Dependency: logback-classic:1.5.9 Java: 17 System: windows 10 Priority: Major Reporter: Ceki Gülcü Description: Problem: when using SizeAndTimeBasedRollingPolicy and setting the maxFileSize field, if logback writes to an already existing log file (a file that was created before running the application), it will not rotate the file if the initial size is already over maxFileSize or if during execution the file exceeds maxFileSize, but it will rotate the log file only after writing maxFileSize bytes to the file, regardless of its actual size Reproducer {code:java} package com.example; import org.slf4j.Logger; import org.slf4j.LoggerFactory; public class App { private static final Logger LOGGER = LoggerFactory.getLogger(App.class); public static void main(String[] args) { for (int i = 0; i < 20000; i++) { LOGGER.info("X".repeat(55)); } } } {code} logback.xml {code:xml} <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE configuration> <configuration> <import class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"/> <import class="ch.qos.logback.core.rolling.RollingFileAppender"/> <import class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"/> <appender name="ROLLING" class="RollingFileAppender"> <rollingPolicy class="SizeAndTimeBasedRollingPolicy"> <fileNamePattern>mylog-%d{yyyy-MM-dd}.%i.txt</fileNamePattern> <maxFileSize>1MB</maxFileSize> <maxHistory>90</maxHistory> <totalSizeCap>20GB</totalSizeCap> </rollingPolicy> <encoder class="PatternLayoutEncoder"> <pattern>%msg%n</pattern> </encoder> </appender> <root level="DEBUG"> <appender-ref ref="ROLLING"/> </root> </configuration> {code} What happens when running the application the first time: If there are no existing log files following the fileNamePattern: 2 log files will be generated properly {code} mylog-2024-10-11.0.txt 1025 KB mylog-2024-10-11.1.txt 90 KB {code} What happens when running the application multiple times after the first: The existing log files keep getting written for maxFileSize bytes and no rotation occurs {code} mylog-2024-10-11.0.txt 2049 KB mylog-2024-10-11.1.txt 179 KB {code} {code} mylog-2024-10-11.0.txt 3073 KB mylog-2024-10-11.1.txt 268 KB {code} ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] (LOGBACK-1775) Last argument of log message stripped if Throwable, even when cause is given as well (Issue #876)
by logback developers list 19 Oct '24

19 Oct '24

1 0

[JIRA] Updates for LOGBACK-1775: Last argument of log message stripped if Throwable, even when cause is given as well (Issue #876)
by logback developers list 19 Oct '24

19 Oct '24

logback / LOGBACK-1775 [Open] Last argument of log message stripped if Throwable, even when cause is given as well (Issue #876) ============================== Here's what changed in this issue in the last few minutes. This issue has been created View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1775 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 19/Oct/24 17:32 Summary: Last argument of log message stripped if Throwable, even when cause is given as well (Issue #876) Issue Type: Bug Affects Versions: 1.5.8 Assignee: Ceki Gülcü Components: logback-classic Created: 19/Oct/24 17:32 Priority: Major Reporter: Ceki Gülcü Description: If a Throwable type is passed to match the last {} argument, it is ignored, and the formatted log message will write {} instead. {code:java} package com.test; import ch.qos.logback.core.Appender; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.slf4j.event.Level; public class Test { static final Logger log = LoggerFactory.getLogger(Test.class); public static void main(String[] args) { log.info("SLF4J Version: {}", Logger.class.getPackage().getImplementationVersion()); log.info("Logback Version: {}", Appender.class.getPackage().getImplementationVersion()); Exception ex = new CustomException("Some message"); log.error("Exception Message: {}", ex, ex); log.makeLoggingEventBuilder(Level.WARN) .setMessage("Exception Message: {}") .addArgument(ex) .setCause(ex) .log(); } static class CustomException extends Exception { public CustomException(String msg) { super(msg); } @Override public String toString() { return "Custom Message"; } } } {code} Expected output: [main] INFO com.test.Test -- SLF4J Version: 2.0.15 [main] INFO com.test.Test -- Logback Version: 1.5.11 [main] ERROR com.test.Test -- Exception Message: Custom Message com.test.Test$CustomException: Some message at com.test.Test.main(Test.java:15) [main] WARN com.test.Test -- Exception Message: Custom Message com.test.Test$CustomException: Some message at com.test.Test.main(Test.java:15) Actual output: [main] INFO com.test.Test -- SLF4J Version: 2.0.15 [main] INFO com.test.Test -- Logback Version: 1.5.11 [main] ERROR com.test.Test -- Exception Message: {} com.test.Test$CustomException: Some message at com.test.Test.main(Test.java:15) [main] WARN com.test.Test -- Exception Message: {} com.test.Test$CustomException: Some message at com.test.Test.main(Test.java:15) Workaround: Explicitly calling .toString() on the argument (log.error("Exception Message: {}", ex.toString(), ex)), or adding a bogus extra "" argument (log.error("Exception Message: {}", ex, "", ex)) works as a work around, but causes static analysis tools, including the one in IntelliJ, to warn about it. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] (LOGBACK-1774) Large log file causing SizeAndTimeBasedRollingPolicy to fail to roll properly
by logback developers list 08 Oct '24

08 Oct '24

1 0