- logback-user - mailman3.qos.ch

dynamically change logging thesholds
by Norbert Kiesel 09 Feb '22

09 Feb '22

Hi, we often need to change log level thresholds to investigate a problem in a running system. Right now, we do that by using <configuration scan="true" scanPeriod="30 seconds"> and then editing the logback.xml file by hand (i.e. using a text editor or Sed or Perl). I wonder if there is a better way to accomplish this. I know that we can e.g. use <root level="${rootLevel}"/> but what I do not yet understand is: 1. Can I modify the value if this variable via some Java API from within my application? 2. Do we still need the scan="true" attribute or will the "rootLevel" variable be evaluated every time the logger is used? 3. Is there a measurable performance impact by using variables in that manner? </nk> --- [MetricStream]<http://www.metricstream.com/> Norbert Kiesel | Chief Architect [https://assets.metricstream.com/lp/email-signature-mail-icon-grey.png] nkiesel(a)metricstream.com<mailto:nkiesel@metricstream.com> [https://assets.metricstream.com/lp/email-signature-mobile-icon-grey.png] +1-650-620-2955 [https://assets.metricstream.com/lp/email-signature-phone-icon-grey.png] +1-650-620-2955 www.metricstream.com<https://www.metricstream.com/> [Linkedin]<https://www.linkedin.com/company/metricstream> [Facebook] <https://twitter.com/metricstream> [Twitter] <https://www.facebook.com/MetricStream> [youtube] <https://www.youtube.com/user/MetricStream> [https://assets.metricstream.com/lp/meticstream-email-signature-stream-bg.png]

2 1

Release of logback version 1.3.0-alpha13
by Ceki Gülcü 31 Jan '22

31 Jan '22

Hello all, I am happy to announce the release of logback version 1.3.0-alpha13. It requires slf4j-api version 2.0.0-alpha5 or later. Starting with this release, future logback releases will be 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. As of version 1.3.0-alpha13, after a Model is created from XML, Model processing is independent of any XML related code. This is was the last major hurdle to implementing new features in the 1.3.x series. For benchmarking figures please see: http://logback.qos.ch/performance.html This version supports the fluent-API introduced in SLF4J 2.0.x. It also supports Jigsaw/Java9 modularization. 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 and Groovy configuration have been dropped temporarily. No new features are available in this version. Future releases will gradually introduce new features made possible by Joran representation model. 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. 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ü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

1 0

%relative pattern 1.3 alpha 11
by Thomas Matthijs 06 Jan '22

06 Jan '22

Hello, Updated to 1.3 alpha 11 and my %relative pattern logging is now a negative number. https://logback.qos.ch/news.html mentions "Logback events now store time using java.time.Instant which supports nanosecond resolution", which may have introduced this bug ? Kind regards

2 2

smtpappender broken in 1.2.9
by Chris Cheshire 24 Dec '21

24 Dec '21

Hi, I upgraded logback to 1.2.9 (from 1.2.3) in my webapp (running under tomcat) and now my SMTPAppender configuration is not working. I have file appenders configured too, but they are all working. Relevant config from logback.xml : <property name="SERVER_NAME" value="XXX" /> <property name="CONTEXT_PATH" value="XXX" /> <property name="LOG_DIR" value="${catalina.base}/logs/${CONTEXT_PATH}" scope="system" /> <appender name="email" class="ch.qos.logback.classic.net.SMTPAppender"> <sessionViaJNDI>true</sessionViaJNDI> <jndiLocation>java:comp/env/mail/XXX</jndiLocation> <to>XXX</to> <from>XXX</from> <subject>XXX</subject> <layout class="ch.qos.logback.classic.PatternLayout"> <pattern>%date{HH:mm:ss.SSS} [%thread] [%level] %logger#%line %n%n%mdc%n%message%n</pattern> </layout> <cyclicBufferTracker class="ch.qos.logback.core.spi.CyclicBufferTracker"> <bufferSize>1</bufferSize> </cyclicBufferTracker> <includeCallerData>true</includeCallerData> </appender> Relevant resource definition in context.xml <Resource name="mail/XXX" auth="Container" type="javax.mail.Session" mail.transport.protocol="smtps" mail.smtp.starttls.enable="true" mail.smtp.host="XXX" mail.smtp.port="587" /> Found in tomcat's default log: 23:51:33,656 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.classic.net.SMTPAppender] 23:51:33,669 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [email] 23:51:33,711 |-INFO in ch.qos.logback.classic.net.SMTPAppender[email] - Looking up javax.mail.Session at JNDI location [java:comp/env/mail/XXX] 23:51:33,720 |-ERROR in ch.qos.logback.classic.net.SMTPAppender[email] - Failed to obtain javax.mail.Session from JNDI location [java:comp/env/mail/XXX] 23:51:33,720 |-ERROR in ch.qos.logback.classic.net.SMTPAppender[email] - Failed to obtain javax.mail.Session. Cannot start. Nothing else was changed, I just uploaded the new jars and restarted tomcat and now it fails. Downgraded to 1.2.7 and SMTPAppender works again.

2 4

Differences between logback 1.2.8 and 1.2.9
by Arjohn Kampman 17 Dec '21

17 Dec '21

Hi, First of all: thank you for looking into the vulnerabilities related to the log4j news. The announcement about the 1.2.9 release is a bit light on details in how it differs from the 1.2.8 release. I thought the 1.2.8 disabled all the critical bits, which makes it safe to use again, but the news article indicates that any version prior to 1.2.9 (including 1.2.8) is vulnerable. So does this mean that 1.2.9 fixes yet more security issues, or is this more about re-enabling some things that have been disabled in 1.2.8? Regards, Arjohn Kampman

2 4

Security Fix - logback 1.2.9 and 1.3.0-alpha11
by Ceki Gülcü 17 Dec '21

17 Dec '21

Hello all, Since the publication of log4shell attack, a vulnerability of lesser importance has been reported against logback, namely CVE-2021-42550. See https://cve.report/CVE-2021-42550 for a description. See https://github.com/cn-panda/logbackRceDemo for a demo of the attack. In response, we have made several changes in logback components as to harden them. We have also dropped Groovy configuration support with no replacement. Please refer to the news page for more details. http://logback.qos.ch/news.html Even if the vulnerability found in logback is less threatening, we highly recommend that you upgrade to logback version 1.2.9 if you are on the 1.2.x series and to version 1.3.0-alpha11 if you are already on 1.3.x series. Best regards, -- Ceki Gülcü Please contact suppport(at)qos.ch for donations, sponsorship or support contracts related to SLF4J or logback projects.

1 0

SECURITY FIX - Release of logback version 1.2.8 with security Fixes
by Ceki Gülcü 14 Dec '21

14 Dec '21

== Includes security fixes ==== Hello all, In the wake of CVE-2021-44228, a serialization related vulnerability has been reported which affects logback. In response to this vulnerability we have disabled all JNDI lookup code in logback until further notice. This impacts ContextJNDISelector and <insertFromJNDI> element in configuration files. We have also removed all database (JDBC) related code in the project with no replacement. We note that the vulnerability mentioned in LOGBACK-1591 [1] requires write access to logback's configuration file as a prerequisite. An demo of the vulnerability can be found at [2]. We urge you to upgrade to logback 1.2.8 as soon as possible. A release on the 1.3.x branch will follow shorty. As an additional precautionary measure, we also recommend users to set their configuration files as read-only. Best regards, [1] https://jira.qos.ch/browse/LOGBACK-1591 [2] https://github.com/cn-panda/logbackRceDemo -- Ceki Gülcü Please contact sales(at)qos.ch for support related to SLF4J or logback projects.

1 0

Log4j Shell zero day vulnerability - does it affect logback or slf4j
by Deepak Abraham 13 Dec '21

13 Dec '21

Hello, Just wanted to check if the log4j vulnerability mentioned here: https://blog.malwarebytes.com/exploits-and-vulnerabilities/2021/12/log4j-ze… Has any equivalent exploit in logback or slf4j users that: - Don't use log4j as a direct dependency- Bridge any log4j calls with org.slf4j:log4j-over-slf4j bridge jar Regards,Deepak.

3 2

How to disable logger output to one of its appenders
by Joud Kassem 30 Nov '21

30 Nov '21

Hi all, I have an "org.geotools" logger with 2 appenders, each appender directs the output to a different file. This is the default configuration in my app. The users have the possibility to override this configuration so maybe a user wants to direct the output of this logger to only one file. It seems that setting the level "OFF" to this logger for one appender doesn't have any effect here, the loggings are still directed to both files (knowing that additivity is set to false). appender("appender1", RollingFileAppender) { file = "${logDir}/Test.log" encoder(PatternLayoutEncoder) { charset = Charset.forName('UTF-8') pattern = log_pattern } rollingPolicy(FixedWindowRollingPolicy) { fileNamePattern = "${logDir}/Test%i.log" minIndex = 1 maxIndex = 2 } triggeringPolicy(SizeBasedTriggeringPolicy) { maxFileSize = FileSize.valueOf("20MB") } } appender("appender2", RollingFileAppender) { file = "${logDir}/stacktrace.log" encoder(PatternLayoutEncoder) { charset = Charset.forName('UTF-8') pattern = log_pattern } rollingPolicy(FixedWindowRollingPolicy) { fileNamePattern = "${logDir}/stacktrace%i.log" minIndex = 1 maxIndex = 2 } triggeringPolicy(SizeBasedTriggeringPolicy) { maxFileSize = FileSize.valueOf("20MB") } } logger("org.geotools", OFF, ['appender1'], false) logger("org.geotools", TRACE, ['appender2'], false) What should I do to be able to disable the logger only in one appender? Thanks in advance!

1 0

Include multiple files
by Jędrzej Dudkiewicz 27 Oct '21

27 Oct '21

Hi, I wrote a question some time ago on stack overflow regarding functionality that I'm looking for: https://stackoverflow.com/questions/64215749/logback-is-there-a-way-to-incl… Unfortunately I only got one comment and it seems that functionality is not there. Is there any way to achieve what I want to do? I hasten to add that our application is a spring-boot based application (based on Tomcat) and we really don't know anything about modules that people write for it - but we know that some people do. I'm pasting my question from SO below: Is there a way to do something along the lines: <configuration> <include file="src/main/java/chapters/configuration/*.xml" />  </configuration> Note *.xml in <include> tag. I have an application consisting of 9 modules, but not all of them are always present. In addition there are external modules that can be installed optionally and I don't know their names in advance (by names I mean class names or config names) or how they should be configured. If there was a way to include files using wildcard I could simply notify developers that they should place their config files in some directory (e.g. config/logging/) and I'd be set for life. Currently files must be included by hand. Of course I could write some code that monitors given file for new configurations and include them programmatically in main configuration file (or proper <include> tags), but maybe there is already a way to do it. -- Jędrzej Dudkiewicz I really hate this damn machine, I wish that they would sell it. It never does just what I want, but only what I tell it.

2 1