April 2020 - logback-user - mailman3.qos.ch

logback prints stack trace twice when writing to syslog
by kumar k 29 Apr '20

29 Apr '20

Hello, I am writing my dropwizard logs to syslog using logback pattern. I see an issue for stack traces prinitng it twice(once linearized and once as multi-line). Is there any parameter which could avoid this issue? Config: syslog: enabled: 'true' threshold: ALL host: localhost facility: local6 logFormat: “MMJ: %p [%logger{0} %t] %c{30} %m [%X]%n %throwable{separator(|)}" *Logs printing twice:* Multiline: 2020-04-27T13:20:46+00:00 MMJ MMJ: ERROR [ConcurrentAuditPersisterQueueSubscriber qe_Event_Queue_AUDIT-1] t.h.w.a.s.ConcurrentAuditPersisterQueueS ubscriber Error processing message payload [] 2020-04-27T13:20:46+00:00 MMJ #011net.liftweb.json.JsonParser$ unknown token <#012Near: *linearized: *2020-04-27T13:20:46+00:00 MMJ MMJ: ERROR [ConcurrentAuditPersisterQueueSubscriber qe_Event_Queue_AUDIT-1] t.h.w.a.s.ConcurrentAuditPersisterQueueS ubscriber Error processing message payload []#012#011net.liftweb.json.JsonParser$ unknown token <#012Near:

1 0

logback prints stack trace twice when writing to syslog
by kumar k 28 Apr '20

28 Apr '20

Hello, I am writing my dropwizard logs to syslog using logback pattern. I see an issue for stack traces prinitng it twice(once linearized and once as multi-line). Is there any parameter which could avoid this issue? Config: syslog: enabled: 'true' threshold: ALL host: localhost facility: local6 logFormat: “MMJ: %p [%logger{0} %t] %c{30} %m [%X]%n %throwable{separator(|)}" *Logs printing twice:* Multiline: 2020-04-27T13:20:46+00:00 MMJ MMJ: ERROR [ConcurrentAuditPersisterQueueSubscriber qe_Event_Queue_AUDIT-1] t.h.w.a.s.ConcurrentAuditPersisterQueueS ubscriber Error processing message payload [] 2020-04-27T13:20:46+00:00 MMJ #011net.liftweb.json.JsonParser$ unknown token <#012Near: *linearized: *2020-04-27T13:20:46+00:00 MMJ MMJ: ERROR [ConcurrentAuditPersisterQueueSubscriber qe_Event_Queue_AUDIT-1] t.h.w.a.s.ConcurrentAuditPersisterQueueS ubscriber Error processing message payload []#012#011net.liftweb.json.JsonParser$ unknown token <#012Near:

1 0

Create rolling file after application startup without losing events?
by Mark Raynsford 18 Apr '20

18 Apr '20

Hello! I have a small application that uses a rolling file appender in addition to logging to the console. I use the following small library to respect the various desktop standards on different platforms: https://www.io7m.com/software/jade/ Essentially, the problem I'm facing is that, for the file output, I don't know exactly where I'm going to log to until very shortly after application startup. Is it possible to defer the instantiation of the rolling file appender until I've worked out where the log files are going to go? I've tried to configure one programmatically, but it seems that the rolling file appender package is not exported. -- Mark Raynsford | https://www.io7m.com

1 0

Java 11 Compatibility
by Jonathan Scherman 07 Apr '20

07 Apr '20

Hi all, Just wanted to know if Logback was Java 11 compatible. The only trail that I've found about this was in the dependencies section <http://logback.qos.ch/dependencies.html> where is specified a requirement of Java 8. I don't understand if this is a strict dependency or just a dependency of Java >= 8. Best, Jonathan

2 1

What's best practices to maintain logger names in backend configuration files like logback.xml?
by Thorsten Schöning 03 Apr '20

03 Apr '20

Hi all, I'm using Logback mostly, but things are the same for other logging backends in the end. My current approach is to maintain `logback.xml` per deployment of some software project, which might be some daemon, web app or whatever. If it has an individual deployment and is known to use logging at all, it gets an individual config file. But should that file contain all logger names known and used by some application? I did so in the past to clearly document which loggers are available at all. Many of those are related to concrete classes and don't need to be configured individually in theory, but the most likely available root logger is enough already. OTOH, there are use cases for very specific loggers which additionally exist per class. Sometimes e.g. I have very special status loggers with very custom logging format which need to write some data to some special fail or send some mail or else. Because those are so special and need to be configured specially, they need to be part of the config file always. The downside of adding all loggers to those files clearly is maintenance overhead: The same logger might be available in multiple files, so renames need to be applied everywhere. Newly added loggers need to be added to all files, but one can't easily know if some class of some package is used in some app only only because some package/project is used in that app. The benefit of this approach clearly is that at best every admin always simply knows which loggers are available by looking into the config and can configure log levels for individual loggers of interest only. Otherwise one would need to start logging and blacklist things clearly not of interest. Does anyone else do this or is it not worth the effort? Thanks! Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: Thorsten.Schoening(a)AM-SoFT.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...........05151- 9468- 55 Fax...............05151- 9468- 88 Mobil..............0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

2 1