- logback-user - mailman3.qos.ch

Documentation glitch
by logback users list 20 Apr '23

20 Apr '23

https://logback.qos.ch/manual/en/index.html (linked as "The logback manual" from https://logback.qos.ch/documentation.html) currently displays Apache HTTP Server Version 2.4 documentation instead.

1 0

Release of logback versions 1.3.6 and 1.4.6
by Ceki Gulcu 15 Mar '23

15 Mar '23

Hello all, I am happy to announce the simultaneous release of logback versions 1.3.6 and 1.4.6. Both versions require slf4j-api version 2.0.x or later. These releases fix several outstanding bugs. For more details, please refer to the the news page: http://logback.qos.ch/news.html We thank LVM Insurances (https://www.lvm.de) for kindly championing these releases. Why two simultaneous releases? 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. The 1.4.x series requires Java 11 at build time and at runtime. Groovy configuration: Support for Groovy configuration was dropped for security reasons but was recovered by Tucker Pelletier (virtualdogbert). See: https://github.com/virtualdogbert/logback-groovy-config Benchmarks: For benchmarking figures please see: http://logback.qos.ch/performance.html Reproducible builds: 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 19. 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 and in particular Spotify R&D and Exoscale. Sponsorship link: https://github.com/sponsors/qos-ch 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

ch.qos.logback.classic.spi.LoggingEvent.getMDCPropertyMap "lazy" evaluation
by Peter Kotula 11 Dec '22

11 Dec '22

Hello everybody, i like to ask, if there is reason why logback/LoggingEvent.java at master · qos-ch/logback | | | | | | | | | | | logback/LoggingEvent.java at master · qos-ch/logback The reliable, generic, fast and flexible logging framework for Java. - logback/LoggingEvent.java at master · qos... | | | is evaluated during call, and not "materialised" during log event creation I seen situations when before LoggingEvent was processed, MDC context was reset, and after that MDC data was not present in related log message thank you very much for answer Best regards Peter Kotula

1 0

insertFromJNDI behavior
by Ove Hiltwein 11 Nov '22

11 Nov '22

Hi, For our tomcat (10.0.23) web application, we use an env-entry to specify the context name in the logback configuration file: <insertFromJNDI env-entry-name="java:comp/env/loggingContextName" as="loggingContextName" /> <contextName>${loggingContextName}</contextName> This context name is also used in defining the log file name: <appender name="ERRORFILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>${logDir}/${loggingContextName}_error_%d{yyyy-MM-dd}.log </fileNamePattern> <maxHistory>7</maxHistory> </rollingPolicy> <encoder> <pattern>%d{ISO8601} %5p [%X{session}] [%c]: %m%n</pattern> </encoder> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>WARN</level> </filter> </appender> And in web.xml we define that environment entry: <env-entry> <env-entry-name>loggingContextName</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>server_v4</env-entry-value> </env-entry> This configuration is in accordance with https://logback.qos.ch/manual/configuration.html. Using logback-classic in version 1.2.11, the corresponding log information is written to the file server_v4_error_2022-11-09.log, as expected. However, after upgrading to logback-classic version 1.4.4 (or 1.3.4), the corresponding log information is written to a file loggingContextName_IS_UNDEFINED_error_2022-11-09.log, and tomcat prints the following to the console during startup: 14:11:58,019 |-ERROR in ch.qos.logback.core.model.processor.DefaultProcessor@1390cc4c - Can't handle model of type class ch.qos.logback.core.model.InsertFromJNDIModel with tag: insertFromJNDI at line 5 What am I missing here? Many thanks Ove Hiltwein -- Ove Hiltwein @ Nebion AG (an Immunai company) / Zurich (CH) www.nebion.com -- PLEASE NOTE: The information contained in this message is privileged and confidential, and is intended only for the use of the individual to whom it is addressed and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, or if any problems occur with the transmission, please contact the sender.

1 0

How to configure logback to NOT truncate stacktraces?
by KARR, DAVID 05 Nov '22

05 Nov '22

I maintain a bunch of SpringBoot services that use logback to configure logging, and slf4j in the Java code. Our log messages currently truncate stacktraces. We're currently using SpringBoot 2.3.12, which pulls in logback-* v1.2.9 and logstash-logback-encoder v6.1. We are working on upgrades, but I can't change these right now. I'd like to be able to configure how much of the stacktrace is truncated, and reverse the order of root causes, so the "rootest" one is shown first. I found several wiki pages on the internet that talk about how to do this, and they were all vague and ambiguous. I tried one that apparently violated the expected logback schema, so it failed to parse it. How can figure out exactly how to do this with the versions of artifacts that I have right now?

1 1

Release of logback versions 1.3.2 and 1.4.2
by Ceki Gülcü 02 Oct '22

02 Oct '22

Hello all, I am thrilled to announce the simultaneous release of logback versions 1.3.2 and 1.4.3. Both versions require slf4j-api version 2.0.x or later. These releases bring improved MDC performance. For other details, please refer to the the news page: http://logback.qos.ch/news.html Why two simultaneous releases? 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 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

testing please ignore
by Ceki Gülcü 29 Sep '22

29 Sep '22

As it says in the subject please ignore -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

1 0

Logback 1.3.0/1.4.0 : slf4j-api & StaticLoggerBinder
by Nigel L Jones 01 Sep '22

01 Sep '22

Hi, I’m a maintainer on the open source Egeria project https://github.com/odpi/egeria. We typically use slf4j in our Java 11 code, and depend on slf4j-api. Then in any ‘applications’ (a client tool, or a server) we include an implementation for logging, such as logback – specifically logback-classic We regularly update our dependencies and today I tried upgrading from logback 1.2.11 to 1.4.0. On doing so I see we now fail to startup, as slf4j is unable to find a logging implementation. Slf4j is at 2.0.0. We get an exception Caused by: java.lang.NoClassDefFoundError: org/slf4j/impl/StaticLoggerBinder Whilst this is an slf4j config issue in most regards, I wonder if the new logback version is not keeping slf4j happy with its implementation in some way I opened up an issue in our own bug tracker at https://github.com/odpi/egeria/issues/6884 which has the dependency tree & stack trace in full. Is there a change in the new version that’s caught us out? Any indications from the log? (If it is a logback issue happy to open up a bug report, but now knowing logback well figured I’d ask here first!) Many thanks Nigel Jones Unless otherwise stated above: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

3 4

Re: [logback-user] logback-user Digest, Vol 126, Issue 5
by Thomas Schittli 31 Aug '22

31 Aug '22

Thank you **very** much, Ceki Gülcü, for your support: Hi Thomas, SiftingAppender is probably what you are looking for. https://logback.qos.ch/manual/appenders.html#SiftingAppender -- Ceki Gülcü it works perfectly and is quite great 😊 Thanks a lot, kind regards, Thomas -----Original Message----- From: logback-user <logback-user-bounces(a)qos.ch> On Behalf Of logback-user-request(a)qos.ch Sent: Wednesday, August 31, 2022 12:00 PM To: logback-user(a)qos.ch Subject: logback-user Digest, Vol 126, Issue 5 Send logback-user mailing list submissions to logback-user(a)qos.ch To subscribe or unsubscribe via the World Wide Web, visit http://mailman.qos.ch/mailman/listinfo/logback-user or, via email, send a message with subject or body 'help' to logback-user-request(a)qos.ch You can reach the person managing the list at logback-user-owner(a)qos.ch When replying, please edit your Subject line so it is more specific than "Re: Contents of logback-user digest..." Today's Topics: 1. Logback FileAppender question: is it able to create log filenames dynamically by a string passed e.g. in LOGGER.trace()? (Thomas Schittli) 2. Re: Logback FileAppender question: is it able to create log filenames dynamically by a string passed e.g. in LOGGER.trace()? (Ceki Gülcü) ---------------------------------------------------------------------- Message: 1 Date: Tue, 30 Aug 2022 12:59:56 +0000 To: "logback-user(a)qos.ch" <logback-user(a)qos.ch> Subject: [logback-user] Logback FileAppender question: is it able to create log filenames dynamically by a string passed e.g. in LOGGER.trace()? Message-ID: <DB7PR04MB44577D12DBC68188909E3C13BD799(a)DB7PR04MB4457.eurprd04.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Good afternoon The documentation for SLF4J and Logback is very detailed 😊, but unfortunately it is still difficult to understand the various possibilities and mechanisms, so I have a question: Is it possible to configure the logback FileAppender so that it automatically / dynamically creates logfile names based on a string which the developer passes in e.g. LOGGER.trace()? The background to the idea is as follows: 1. The developer is programming a new module (e.g. a configuration manager) and he would like to have the log entries summarised in a separate log file. 2. Therefore, he calls something like that: LOGGER.trace(“Config-Mgr”, “Message”) 3. SLF4J / Logback automatically reads this string and create this Logfile: AppLog-Config-Mgr.log 4. The central element is that we do not have to modify logback.xml and create an appender for each Logfile. This means that if the user now calls e.g.: LOGGER.trace(“User-Actionlog”, “Message”) then this new log file will created without having to modify logback.xml: AppLog-User-Actionlog.log Thank you very much for any tips & tricks 😊 Thanks a lot, kind regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.qos.ch/pipermail/logback-user/attachments/20220830/4df874c5/…> ------------------------------ Message: 2 Date: Tue, 30 Aug 2022 21:26:44 +0200 To: logback-user(a)qos.ch Subject: Re: [logback-user] Logback FileAppender question: is it able to create log filenames dynamically by a string passed e.g. in LOGGER.trace()? Message-ID: <5b9c4fee-2451-bcc7-f9ad-c0af38e48a73(a)qos.ch> Content-Type: text/plain; charset=UTF-8 Hi Thomas, SiftingAppender is probably what you are looking for. https://logback.qos.ch/manual/appenders.html#SiftingAppender -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 8/30/2022 2:59 PM, Thomas Schittli wrote: > Good afternoon > > > > The documentation for SLF4J and Logback is very detailed 😊, but > unfortunately it is still difficult to understand the various > possibilities and mechanisms, so I have a question: > > > > Is it possible to configure the logback FileAppender so that it > automatically / dynamically creates logfile names based on a string > which the developer passes in e.g. LOGGER.trace()? > > > > The background to the idea is as follows: > > > > 1. The developer is programming a new module (e.g. a configuration manager) > and he would like to have the log entries summarised in a separate > log file. > > 2. Therefore, he calls something like that: LOGGER.trace(“Config-Mgr”, > “Message”) > > 3. SLF4J / Logback automatically reads this string and create this > Logfile: AppLog-Config-Mgr.log > > > 4. The central element is that we do not have to modify logback.xml and > create an appender for each Logfile. > > This means that if the user now calls e.g.: > LOGGER.trace(“User-Actionlog”, “Message”) > then this new log file will created without having to modify > logback.xml: > AppLog-User-Actionlog.log > > > > > Thank you very much for any tips & tricks 😊 > > Thanks a lot, kind regards, > Thomas > > ------------------------------ Subject: Digest Footer _______________________________________________ logback-user mailing list logback-user(a)qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user ------------------------------ End of logback-user Digest, Vol 126, Issue 5 ********************************************

1 0

Logback FileAppender question: is it able to create log filenames dynamically by a string passed e.g. in LOGGER.trace()?
by Thomas Schittli 30 Aug '22

30 Aug '22

Good afternoon The documentation for SLF4J and Logback is very detailed 😊, but unfortunately it is still difficult to understand the various possibilities and mechanisms, so I have a question: Is it possible to configure the logback FileAppender so that it automatically / dynamically creates logfile names based on a string which the developer passes in e.g. LOGGER.trace()? The background to the idea is as follows: 1. The developer is programming a new module (e.g. a configuration manager) and he would like to have the log entries summarised in a separate log file. 2. Therefore, he calls something like that: LOGGER.trace(“Config-Mgr”, “Message”) 3. SLF4J / Logback automatically reads this string and create this Logfile: AppLog-Config-Mgr.log 4. The central element is that we do not have to modify logback.xml and create an appender for each Logfile. This means that if the user now calls e.g.: LOGGER.trace(“User-Actionlog”, “Message”) then this new log file will created without having to modify logback.xml: AppLog-User-Actionlog.log Thank you very much for any tips & tricks 😊 Thanks a lot, kind regards, Thomas

2 1