- logback-user - mailman3.qos.ch

Release of logback versions 1.3.0 and 1.4.0
by Ceki Gülcü 28 Aug '22

28 Aug '22

Hello all, I am thrilled to announce the simultaneous release of logback versions 1.3.0 and 1.4.0. Both versions require slf4j-api version 2.0.0 or later. Given that downstream users are likely to depend on either Java EE (in the javax namespace) or on Jakarta EE (in the jakarta namespace) in their projects, it was deemed important for logback to support both EE alternatives. As such, logback 1.3.x supports Java EE whereas logback 1.4.x supports Jakarta EE, otherwise the two versions are feature identical. Both 1.3.x and 1.4.x series require the fluent-API introduced in SLF4J 2.0.x. The 1.3.x series requires Java 8 at runtime. If you wish to build logback from source, you will need Java 9. Reproducible builds require Java 18. The 1.4.x series requires Java 11 at build time and at runtime. ------------------ Joran, logback's configuration system, has been rewritten to use an internal representation model which can be processed separately. Given the breadth of the changes, support for SiftingAppender was dropped temporarily and reintroduced in logback version 1.3.0-alpha16. Support for Groovy configuration was dropped for security reasons but was recovered by Tucker Pelletier (virtualdogbert). See: https://github.com/virtualdogbert/logback-groovy-config For benchmarking figures please see: http://logback.qos.ch/performance.html Recent logback releases are reproducible. This means that anyone checking out the code corresponding to the release version from github and building that local copy, will get obtain an identical binary to the binary found on Maven central. Note that due to issue MJAR-275 with the module-info.java produced in earlier java versions, reproducible builds require Java 18. Donations and sponsorship You can also support SLF4J/logback/reload4j projects via donations and sponsorship. We thank our current supporters and sponsors for their continued contributions. Sponsorship link: https://github.com/sponsors/qos-ch?o=esb Announcement mailing list: You can receive SLF4J/logback/reload4j related announcements by subscribing QOS.ch announce list, please visit the following URL. http://www.qos.ch/mailman/listinfo/announce Enjoy, -- Ceki Gülcü

1 0

Strategy for supporting both Java EE and Jakarta EE in logback distributions
by Ceki Gülcü 25 Aug '22

25 Aug '22

Hello all, I just started a discussion on supporting both Java EE and Jakarta EE in logback. Here is the link: https://github.com/qos-ch/logback/discussions/585 Do not hesitate to chime in. -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

1 0

Required Logback.xml utility
by Vijayakrishna Boggavarapu 12 Aug '22

12 Aug '22

Hi Team, How are you? Hope everything is going well on your end. We are searching for a tool similar to a jar or shell script that can convert a log4j.properties file into a logback.xml file after receiving it from the user. Please let us know if you have a utility or any specific instructions we can follow to convert the log4j.properties file to a logback.xml one. Thanks, Vijayakrishna DevOps Engineer Sr., WFM [cid:image001.png@01D8AE78.6D690FA0]<https://www.credly.com/badges/96317f21-42d3-4d05-a266-2db5657a8936/public_u…>

2 2

Proper legacy bridging and initialization, by example
by Zac Harvey 28 Jul '22

28 Jul '22

Hello I just want to make sure I am understanding your user manual (specifically https://www.slf4j.org/legacy.html) correctly: Sounds like if I put the following JARs on my runtime classpath I can pump logs made from other logging systems and send them to the same SLF4J appenders my app is using: - jcl-over-slf4j.jar --> JCL - log4j-over-slf4j.jar --> Log4J - jul-to-slf4j.jar --> JUL - requires I call two SLF4JBridgeHandler methods ( removeHandlersForRootLogger() and install()) at app startup in order to work Am I understanding this correctly? Thanks in advance!

2 1

MDC scopes on Spring Boot applications
by Zac Harvey 27 Jul '22

27 Jul '22

I'm interested in utilizing the Mapped Diagnostic Context (MDC) <https://logback.qos.ch/manual/mdc.html> but have two types of MDC needs: - *global*: I need to add certain key-value pairs to the MDC when the server starts up, and I need them present in every log message for the entire life of the server; and - *request-scoped* (thread scoped?): certain key-value pairs need to be added to the MDC but will change for every/most HTTP request the server receives I know that MDC is thread-safe, so I'm guessing each HTTP request will have its own "blank slate" version/instance of the MDC to work with, which takes care of my request-scoped needs. But from inside request handlers (servlet filters, Spring controllers, etc.) I still need the global MDC key-value pairs present in any log messages that are made. For example, say, at server startup I need to add: MDC.put("Server-Instance-Id", serverInstanceId); I will need "*Server-Instance-Id*" in every single log message sent, regardless of what thread/request the log message is sent from. But then say in my FizzController#getFizzes() method, which accepts HTTP requests to, say, GET /v1/fizzes, I have: MDC.put("Fruit", pear.getName());logger.info("User is requested all fizzes"); In this case above, I would want *both* "*Server-Instance-Id*" and "*Fruit*" values included in the log message. Similarly, if I clear the MDC (MDC.clear()) from inside a request thread (such as a call to FizzController#getFizzes()), I don't want it to clear the global context variables (such as "*Server-Instance-Id*"). Only clear the request-scoped ones. Does anyone know how to accomplish this with SLF4J config or its API?

2 1

Custom appender is being ignored
by Zac Harvey 26 Jul '22

26 Jul '22

Java 11 and logback-classic-1.2.11 here. I'm trying to write my own custom appender and am following this Baeldung article <https://www.baeldung.com/custom-logback-appender> to test it out. My *src/main/java/myapp/logging/CatAppender* appender (on the runtime classpath): public class CatAppender extends AppenderBase<ILoggingEvent> { @Override protected void append(ILoggingEvent eventObject) { System.out.println("meow"); } } My *src/main/resources/logback.xml*: <?xml version="1.0" encoding="UTF-8"?> <configuration debug="true"> <appender name="cat" class="myapp.logging.CatAppender"/> <root level="info"> <appender-ref ref="cat" /> </root> </configuration> In my *build.gradle* I specify to use logback and Lombok: plugins { id "io.freefair.lombok" version '6.4.0' } dependencies { implementation ( 'ch.qos.logback:logback-classic:1.2.11' ,'org.projectlombok:lombok:1.18.16' ) } And then in my Java code I use Lombok to inject an SLF4J logger like so: @Slf4j public class SomethingDoer { public void doSomething() { log.info("this should invoke the CatAppender..."); } } But when *SomethingDoer#doSomething()* runs, I don't see a meow printed to my STDOUT console. Have I wired anything up incorrectly here?

3 6

Can an appender pattern be varied based on MDC?
by Mark Raynsford 24 Jun '22

24 Jun '22

Hello! I have an application where parts of the application set a "domain" MDC value where appropriate, and unset it later when it's no longer applicable. I'd like to use something like the following when "domain" is set: <appender name="STDERR" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%level %logger [%X{domain}] %msg%n</pattern> </encoder> </appender> ... and something like the following when "domain" _isn't_ set: <appender name="STDERR" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%level %logger %msg%n</pattern> </encoder> </appender> Is this possible? I'm not seeing anything in the manual that would suggest it is. -- Mark Raynsford | https://www.io7m.com

2 2

Logs not rolling over
by Trent Phillips 16 Jun '22

16 Jun '22

Have been using logback since 2019. Logback.xml is dated 2019 as last change. One of our apps now has a lot more traffic. For some reason, this is causing the rollover to not happen at/around midnight. It creates the daily .gz file and names it appropriately, but keeps appending to the same file. On Day 1, the unzipped log file is 50 MB. By the end of the second day, it has become 112MB. Everynight or early the next morning, it creates a new gz file but does not truncate the existing file. By Day 7, the unzipped file is now over 500MB and the zip fails everynight. Still no truncation. So, the change is that now this application is getting a lot of hits. Why won't the file truncate, and zip at the end of the day? No changes to the logback.xml. I can try to use the limit file size option, but the multiple files created will potentially break our log analyzer. The only way to truncate the file is to stop and start Tomcat, which we are reluctant to do. What should I do to fix this? THanks, Trent

1 0

Callerdata on error severity
by Niklas Dusenlund 13 Jun '22

13 Jun '22

Hey! Is it possible to only have callerData on the error severity? Cheers

1 0

Fwd: Publish a project that use logback under MIT license
by Stefano 10 Jun '22

10 Jun '22

Hi all, The project is a Java library that contains logback <https://github.com/qos-ch/logback> as a dependency. Since logback is published under EPLv1 I'm wondering if I can publish my project under MIT license. What do you think about it? Thanks, Stefano

2 1