- logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1711) Deadlock when using Virtual Threads
by logback developers list 27 Mar '24

27 Mar '24

1 0

[JIRA] (LOGBACK-1748) JsonEncoder: allow configuring to get formatted message in the json payload
by logback developers list 02 Feb '24

02 Feb '24

1 0

[JIRA] (LOGBACK-1748) JsonEncoder: allow configuring to get formatted message in the json payload
by logback developers list 02 Feb '24

02 Feb '24

1 0

[Discussion] Deleting log files by last modified date
by logback developers list 26 Jan '24

26 Jan '24

https://github.com/qos-ch/logback/issues/764 I noticed that Logback uses a for loop to generate what it expects the log file name to be and the directory it's in. Is there any reason why it can't loop through the log output directory and match the log name and delete them if they're outside the roll over window?

1 0

test
by logback developers list 25 Sep '23

25 Sep '23

test

1 0

[JIRA] Updates for LOGBACK-1765: MDC Properties Not Associated with Log Statements
by logback developers list 14 Sep '23

14 Sep '23

logback / LOGBACK-1765 [Open] MDC Properties Not Associated with Log Statements ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1765 ============================== Issue created ------------------------------ Naser Ayat created this issue on 14/Sep/23 9:48 Summary: MDC Properties Not Associated with Log Statements Issue Type: Bug Affects Versions: 1.4.11, 1.4.8, 1.4.9 Assignee: Logback dev list Components: logback-classic Created: 14/Sep/23 9:48 Environment: macOS Ventura 13.6.2 OpenJDK 17.0.8 Spring Boot 3.1.3 Labels: MDC Priority: Major Reporter: Naser Ayat Description: Starting from version 1.4.8 of Logback, an issue has been observed where MDC properties are no longer associated with log statements when a custom {{{}MDCAdapter{}}}, for instance {{{}com.twitter.inject.logging.FinagleMDCAdapter{}}}, is set in the application. The likely root cause is that, beginning with version 1.4.8, Logback obtains the MDCAdapter from {{{{ch.qos.logback.classic.LoggerContext}}}} instead of directly getting it from MDC. Consequently, the application ends up using two separate and independent MDCAdapters concurrently. You can find a simplified application created to reproduce this issue in the following repository: [https://github.com/naser-ayat/logback-bug-reproducer] ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for LOGBACK-1764: Mark FixedWindowRollingPolicy as deprecated
by logback developers list 11 Sep '23

11 Sep '23

logback / LOGBACK-1764 [Open] Mark FixedWindowRollingPolicy as deprecated ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1764 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 11/Sep/23 20:45 Summary: Mark FixedWindowRollingPolicy as deprecated Issue Type: Bug Assignee: Logback dev list Components: logback-core Created: 11/Sep/23 20:45 Environment: https://twitter.com/fcamblor/status/1701214482339447231 Priority: Major Reporter: Ceki Gülcü ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

Encoder field processor
by logback developers list 11 Sep '23

11 Sep '23

Hello In extension to https://github.com/qos-ch/logback/discussions/698#discussioncomment-6849417. I wanted to propose making an injectable FieldProcesssor bean for Encoder. Where you can specify how the message will be generated. By default, data will be processed as it is currently in ch.qos.logback.classic.encoder.JsonEncoder And if needed, it could be extended to change behavior. For example, time could be converted to UTF format. Or the message could be sent not as a string, but as a JSON object. Best regards, Mikl

1 0

Support Removal of ConfigurationEventListener
by logback developers list 08 Sep '23

08 Sep '23

I refer to commit dd2b9fe93afafa61e1aa1f89832c151bfb35920c that enabled the Context interface to handle a ConfigurationEvent. Currently, there is only a method to register a ConfigurationEventListener. It would be useful to have another method to deregister such a listener. What's more, the current source describes the registration method as follows: "The propagation of {@link ConfigurationEvent configuration events} is intended for internal testing as well as some coordination between configurators." I believe a ConfigurationEvent is generally useful. The documentation should acknowledge that. BACKGROUND I use Logback in a Spring web application and need to register LoggingEvent filter beans programmatically. This requires to hook into Spring's lifecycle and to perform registration / deregistration on bean initialization and destruction. Special attention needs to be taken to Logback's configuration reload. In this case I need to hook into ReconfigureOnChangeTask to realize when reload has ended since all filter beans need to be registered again. This can be performed with the help of listeners, all of which have some drawbacks: * LoggerContextListener#onReset( context) : This fires before the Logback configuration file has been read and thus, before appenders are available. Registration of LoggingEvent filters is not possible here. * StatusListener#addStatusEvent( status) : Fires more often (on each status message). It is hard to realize the "end of configuration" state from just a message, a level and the notifying instance. This also does not seem like a stable and consistent solution to me. * ReconfigureOnChangeTaskListener#doneReconfiguring( ) : Could be the right choice but is currently unused, package-private and was probably never intended for general usage. * ConfigurationEventListener#listen( configurationEvent) : Seems to be ideal since one can identify the end of Logback's configuration (ConfigurationEvent#CONFIGURATION_ENDED). This, however, does not offer a method to deregister a corresponding listener. The point is I need to cleanup resources on shutdown of Spring's ApplicationContext because Logback's LoggerContext is a shared singleton that survives Spring. It should be easy to add a deregistration method here. Any opinion / suggestion? Regards, Mathias

1 0

[JIRA] (LOGBACK-1756) Change LoggerContext to use MDCAdapter instead of LogbackMDCAdapter
by logback developers list 05 Sep '23

05 Sep '23

1 0