- logback-user - mailman3.qos.ch

How to change the log level label with slf4j?
by Frédérick Sauvage Rueangpanichpiban 02 Jun '22

02 Jun '22

Hi all I'm trying to change the label in the log. I only want to get {"level":"WARNING","msg":"test"} instead of {"level":"WARN","msg":"test"}. My class is: package com.abc.def; import org.slf4j.Logger;import org.slf4j.LoggerFactory;import org.springframework.boot.SpringApplication;import org.springframework.boot.autoconfigure.SpringBootApplication;import org.springframework.boot.builder.SpringApplicationBuilder;import org.springframework.boot.web.servlet.support.SpringBootServletInitializer; @SpringBootApplicationpublic class Application extends SpringBootServletInitializer { private static final Logger LOG = LoggerFactory.getLogger(Application.class); @Override protected SpringApplicationBuilder configure(SpringApplicationBuilder application) { return application.sources(Application.class); } public static void main(String[] args) { LOG.warn("test"); SpringApplication.run(Application.class, args); } } My logback.xml file is: <?xml version="1.0" encoding="UTF-8"?> <configuration> <property resource="application.properties" /> <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"> <encoder class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder"> <providers> <logLevel> <fieldName>level</fieldName> </logLevel> <arguments> <includeNonStructuredArguments>false</includeNonStructuredArguments> </arguments> <stackTrace> <fieldName>stack</fieldName> </stackTrace> <message> <fieldName>msg</fieldName> </message> </providers> </encoder> </appender> <root level="INFO"> <appender-ref ref="CONSOLE" /> </root> </configuration> I tried many changes but finally I don't any solution except creating a new class that extends net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder. That seems a big stuff for a very small change. I posted already in stackoverflow https://stackoverflow.com/questions/72476767/how-to-change-the-log-level-la… Thanks for helps

1 0

Issues with logback and maven/shading.
by Adam Somerville 17 May '22

17 May '22

Hi I work for Lyniate and I am trying to use logback in one of our products. For the most part things are great, expect for one niche issue I have been stuck on for days. It’s a little complex: Overall, I am building a jar that people can incorporate into their own applications. It is built with maven, when I include logback a dependency it works. However, when I try to shade logback in the jar it seems to ignore my configuration properties files. i.e. I cannot see any log file when I run. This only occurs in the built jar, I cannot reproduce in a dev environment at all, and as mentioned it only ignores config when shading logback. Here are the relevant code snippets: final URL url = ClassLoader.getSystemResource(config); if (url == null) { throw new IOException("Unable to find logback configuration file '" + config + "' on the classpath."); } System.out.print("URL found: " + url.toExternalForm()); try { this.filepath = Paths.get(url.toURI()).toAbsolutePath(); this.filename = filepath.getFileName().toString(); this.factory = loadConfig(filepath); .... (init watch service) … } catch (Exception e) { e.printStackTrace(System.err); throw new IOException("Failed to configure logback using configuration file '" + this.filepath + "'.", e); } and private static ILoggerFactory loadConfig(final Path config) throws IOException { try { final JoranConfigurator configurator = new JoranConfigurator(); //final LoggerContext context = (LoggerContext) LoggerFactory.getILoggerFactory(); final LoggerContext context = new LoggerContext(); dumpDebugInformation(context); configurator.setContext(context); context.reset(); configurator.doConfigure(config.toFile()); final LevelChangePropagator levelChangePropagator = new LevelChangePropagator(); levelChangePropagator.setContext(context); context.addListener(levelChangePropagator); return context; } catch (final JoranException e) { throw new IOException("An error occured configuring the RMT logger with file", e);//TODO Better error message } } FYI am also initialising a java watch service in the constructor where the first snippet is called, not shown above thought I better mention in case it is relevant. When the code executes I get the correct output for all the paths and what looks to be the right object. However, it does not produce my log file. this.filepath: <correct path>\libs\RMTLogging.xml this.factory (name): ch.qos.logback.classic.LoggerContext. This is the same as output as when it is working. It seems like it is not binding to SLF4J correctly. I have tried both: final LoggerContext context = (LoggerContext) LoggerFactory.getILoggerFactory(); and final LoggerContext context = new LoggerContext(); I suspected the shading is somehow interfering with binding to SLF4J but instantiating the LoggerContext directly does not seem to make a difference. There are no errors or exceptions. Just no log file when I try and shade logback into my final built jar. Which means even though it has the correct config file path and appears load it, seems it is not really being configured. Below are my settings file. It works in dev environment and a non-shaded jar. When it is shaded with the same config it just does not work. <?xml version="1.0" encoding="UTF-8"?> <configuration> <appender name="Main" class="ch.qos.logback.core.rolling.RollingFileAppender">  <File>Result.log</File> <encoder>  <pattern>%d{DATE} [%-5p] {%t} $%c$ %m%n</pattern> </encoder> <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> <maxIndex>9</maxIndex> <FileNamePattern>Result.log.%i</FileNamePattern> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> <MaxFileSize>5MB</MaxFileSize> </triggeringPolicy> </appender> <logger name="com.orion.symphonia3.MessageFactory" level="ERROR"> <appender-ref ref="Main" /> </logger> <logger name="com.orion.symphonia3.RhapsodyLicenseCheck" level="DEBUG"> <appender-ref ref="Main" /> </logger> <logger name="com.orion.symphonia3.MessageWarehouseDefn" level="DEBUG"> <appender-ref ref="Main" /> </logger> <logger name="load.Message" level="DEBUG"> <appender-ref ref="Main" /> </logger> (Etc many more loggers) The shading is fairly critical for us. There are several other shaded third party jars, with no issues. It just seems to be just the configuration part of logback that causes these issue. Any ideas as to what is happening? If you need more information, please let me know. Kind Regards Adam Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.

2 2

Issues with logback and maven/shading.
by Adam Somerville 16 May '22

16 May '22

Hi I work for Lyniate and I am trying to use logback in one of our products. For the most part things are great, expect for one niche issue I have been stuck on for days. It's a little complex: Overall, I am building a jar that people can incorporate into their own applications. It is built with maven, when I include logback a dependency it works. However, when I try to shade logback in the jar it seems to ignore my configuration properties files. i.e. I cannot see any log file when I run. This only occurs in the built jar, I cannot reproduce in a dev environment at all, and as mentioned it only ignores config when shading logback. Here are the relevant code snippets: final URL url = ClassLoader.getSystemResource(config); if (url == null) { throw new IOException("Unable to find logback configuration file '" + config + "' on the classpath."); } System.out.print("URL found: " + url.toExternalForm()); try { this.filepath = Paths.get(url.toURI()).toAbsolutePath(); this.filename = filepath.getFileName().toString(); this.factory = loadConfig(filepath); .... (init watch service) ... } catch (Exception e) { e.printStackTrace(System.err); throw new IOException("Failed to configure logback using configuration file '" + this.filepath + "'.", e); } and private static ILoggerFactory loadConfig(final Path config) throws IOException { try { final JoranConfigurator configurator = new JoranConfigurator(); //final LoggerContext context = (LoggerContext) LoggerFactory.getILoggerFactory(); final LoggerContext context = new LoggerContext(); dumpDebugInformation(context); configurator.setContext(context); context.reset(); configurator.doConfigure(config.toFile()); final LevelChangePropagator levelChangePropagator = new LevelChangePropagator(); levelChangePropagator.setContext(context); context.addListener(levelChangePropagator); return context; } catch (final JoranException e) { throw new IOException("An error occured configuring the RMT logger with file", e);//TODO Better error message } } FYI am also initialising a java watch service in the constructor where the first snippet is called, not shown above thought I better mention in case it is relevant. When the code executes I get the correct output for all the paths and what looks to be the right object. However, it does not produce my log file. this.filepath: <correct path>\libs\RMTLogging.xml this.factory (name): ch.qos.logback.classic.LoggerContext. This is the same as output as when it is working. It seems like it is not binding to SLF4J correctly. I have tried both: final LoggerContext context = (LoggerContext) LoggerFactory.getILoggerFactory(); and final LoggerContext context = new LoggerContext(); I suspected the shading is somehow interfering with binding to SLF4J but instantiating the LoggerContext directly does not seem to make a difference. There are no errors or exceptions. Just no log file when I try and shade logback into my final built jar. Which means even though it has the correct config file path and appears load it, seems it is not really being configured. Below are my settings file. It works in dev environment and a non-shaded jar. When it is shaded with the same config it just does not work. <?xml version="1.0" encoding="UTF-8"?> <configuration> <appender name="Main" class="ch.qos.logback.core.rolling.RollingFileAppender">  <File>Result.log</File> <encoder>  <pattern>%d{DATE} [%-5p] {%t} $%c$ %m%n</pattern> </encoder> <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> <maxIndex>9</maxIndex> <FileNamePattern>Result.log.%i</FileNamePattern> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> <MaxFileSize>5MB</MaxFileSize> </triggeringPolicy> </appender> <logger name="com.orion.symphonia3.MessageFactory" level="ERROR"> <appender-ref ref="Main" /> </logger> <logger name="com.orion.symphonia3.RhapsodyLicenseCheck" level="DEBUG"> <appender-ref ref="Main" /> </logger> <logger name="com.orion.symphonia3.MessageWarehouseDefn" level="DEBUG"> <appender-ref ref="Main" /> </logger> <logger name="load.Message" level="DEBUG"> <appender-ref ref="Main" /> </logger> (Etc many more loggers) The shading is fairly critical for us. There are several other shaded third party jars, with no issues. It just seems to be just the configuration part of logback that causes these issue. Any ideas as to what is happening? If you need more information, please let me know. Kind Regards Adam Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.

1 0

Support for multiple %replace, formatted for better readability?
by Thorsten Schöning 05 May '22

05 May '22

Hi everyone, I have a XML config file and am trying to apply multiple different %replace statements on the message text. the only thing which seems to work is nest multiple of those statements, resulting in pretty long lines. Is there some way to get things better readable, like spanning multiple lines or alike? Whatever I tried resulted in different parser errors within Logback, e.g. in the following cases: > %replace > ( > %replace(...){...} > ){...} Thanks! Mit freundlichen Grüßen Thorsten Schöning -- AM-SoFT IT-Service - Bitstore Hameln GmbH Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK E-Mail: Thorsten.Schoening(a)AM-SoFT.de Web: http://www.AM-SoFT.de/ Tel: 05151- 9468- 0 Tel: 05151- 9468-55 Fax: 05151- 9468-88 Mobil: 0178-8 9468-04 AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. Mit freundlichen Grüßen, Thorsten Schöning Telefon: +49 (0)515 94 68 - 0 Fax: E-Mail: TSchoening(a)am-soft.de AM-Soft IT-Service - Bitstore Hameln GmbH Brandenburger Straße 7c 31789 Hameln Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen und ist ausschliesslich für den Adressaten bestimmt. Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im Vertrauen auf erlangte Information untersagt. This e-mail may contain confidential and/or privileged information and is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Hinweise zum Datenschutz: bitstore.group/datenschutz

1 1

Support for multiline config strings in XML files using PatternLayoutEncoder?
by Thorsten Schöning 05 May '22

05 May '22

Hi everyone, I have a XML config file and tried to use the following lines to make things a bit more readable: > <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> > <charset>UTF-8</charset> > <pattern> > %d{yyyy-MM-dd HH:mm:ss} > %-22class{0}: > %replace(%msg){'RCV_.+?: ', ''} > %n > </pattern> > </encoder> But this results in multiline output, most likely forwarding the XML newlines: > 2022-05-05 15:22:30 > WrkBase : > config\..\data\[...] > > 2022-05-05 15:22:30 > WrkRcvZipWithVakteCopy: > [...].zip Is there some setting or alike I'm using to not get the XML newlines in the output? Would even be great to be able to switch between removing all of those and e.g. replacing with one space only instead. Thanks! Mit freundlichen Grüßen Thorsten Schöning -- AM-SoFT IT-Service - Bitstore Hameln GmbH Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK E-Mail: Thorsten.Schoening(a)AM-SoFT.de Web: http://www.AM-SoFT.de/ Tel: 05151- 9468- 0 Tel: 05151- 9468-55 Fax: 05151- 9468-88 Mobil: 0178-8 9468-04 AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. Mit freundlichen Grüßen, Thorsten Schöning Telefon: +49 (0)515 94 68 - 0 Fax: E-Mail: TSchoening(a)am-soft.de AM-Soft IT-Service - Bitstore Hameln GmbH Brandenburger Straße 7c 31789 Hameln Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen und ist ausschliesslich für den Adressaten bestimmt. Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im Vertrauen auf erlangte Information untersagt. This e-mail may contain confidential and/or privileged information and is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Hinweise zum Datenschutz: bitstore.group/datenschutz

1 0

Current version of logback can't read my JNDI entry
by Hendrik Stichweh 31 Mar '22

31 Mar '22

I'm running a program on a WebSphere Liberty 21.0.0.11 with logging from logback 1.2.11. I have a log output folder specified in my server.xml as: <jndiEntry jndiName="logging/logPath" value="${server.output.dir}/logs"/> In the logback.xml I read this entry with the line: <insertFromJNDI env-entry-name="logging/logPath" as="logPath"/> This worked in the old logback versions However in the new version of logback this name is not allowed as the name now must start with "java:". So when I tried to change the line to: <insertFromJNDI env-entry-name="java:comp/env/logging/logPath" as="logPath"/> I get 14:37:59,720 |-ERROR in ch.qos.logback.classic.joran.action.InsertFromJNDIAction - Failed to lookup JNDI env-entry [java:comp/env/stibam/logPath] javax.naming.NamingException: CWNEN1000E: Is there an error in my reading out of that JNDI variable?

2 3

Attach custom Logback appenders after configuration reload
by Thaya Nathan 16 Mar '22

16 Mar '22

Hi Team, We have been migrating from Log4j 1 to Logback and we have few custom appenders like below: *public class CustomAppender extends AppenderBase<ILoggingEvent> implements Runnable {}* Those attach to ch.qos.logback.classic.Logger using addAppender method when application starts. All these programmatically created appenders are removed when the Logback configuration file (logback.xml) changed/reloaded. How can we re attach those appenders back to Logger without application restart? Thanks, Thaya

1 0

Re: [logback-user] Logback 1.3 status
by Daniel Bower 11 Mar '22

11 Mar '22

Thanks for the update. It is very much appreciated. > Hello Daniel, > > SLF4J 2.0 is still in alpha as the Fluent API has not been finalized. > At present time, that is the main reason logback 1.3 is still in alpha. > > Logback 1.3 is close to being feature complete and should enter a beta > release cycle very soon. > > Ceki Gülcü

1 0

Logback 1.3 status
by Daniel Bower 10 Mar '22

10 Mar '22

I'm curious if there are any blockers for 1.3 to exit alpha. Is there a roadmap of features, or a good place I can go to see status? I was looking at the news page, the logback-user mailing list and the logback-dev mailing list. I may have missed it though. There are some very nice features in 1.3, and I was trying to gauge how close it was to release. Thanks!

2 1

Async File Appender stopped working since 1.3.0-alpha13
by c.ahlers＠gmx.net 11 Feb '22

11 Feb '22

Since 1.3.0-alpha13, my AsyncAppender referencing a FileAppender stopped working. It works in 1.3.0-alpha12 and before. Using the FileAppender directly still works, so the issue is the AsyncAppender. The problem is that it does not write anything to the file when it should have written 23 lines to the log file. My configuration is straight forward: https://github.com/Ahli/Galaxy-Observer-UI/blob/ba81d7ac331a258da2ddcce446ef d4d8c2d1e0ba/tools/observerUiSettingsEditor/project/src/main/resources/logba ck.xml I use it in combination with slf4j 2.0.0-alpha6 in a JDK 17 project that does not use any frameworks. I have tried the current snapshot of alpha14, but my issue is still present. Are there migrations necessary that were not announced in the news post or is this a bug?

2 2