- logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1711) Deadlock when using Virtual Threads
by logback developers list 21 Jun '23

21 Jun '23

1 0

[JIRA] Updates for LOGBACK-1747: Allow subclasses of LoggerContext to customize new Logger instances
by logback developers list 20 Jun '23

20 Jun '23

logback / LOGBACK-1747 [Open] Allow subclasses of LoggerContext to customize new Logger instances ============================== 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-1747 ============================== Issue created ------------------------------ Richard Sand created this issue on 20/Jun/23 16:58 Summary: Allow subclasses of LoggerContext to customize new Logger instances Issue Type: Improvement Assignee: Logback dev list Components: logback-classic Created: 20/Jun/23 16:58 Priority: Major Reporter: Richard Sand Description: I've a use case where I am adapting Logback to work with a legacy product's proprietary log mechanism. I did this by creating a wrapper class around a {{Logger. }}But there is no hook to programmatically touch the {{Logger}} instances at creation-time. I submitted a pull request #635 ([https://github.com/qos-ch/logback/pull/635) that addresses this by simply adding a method to {{LoggerContext }}that is invoked immediately after {{{}Logger.createChildByName(){}}}, which by default is a no-op but can be implemented by custom contexts. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for LOGBACK-1746: insertFromJNDI fails in 1.4.6
by logback developers list 20 Jun '23

20 Jun '23

logback / LOGBACK-1746 [Open] insertFromJNDI fails in 1.4.6 ============================== 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-1746 ============================== Issue created ------------------------------ Richard Sand created this issue on 20/Jun/23 16:42 Summary: insertFromJNDI fails in 1.4.6 Issue Type: Bug Affects Versions: 1.4.6 Assignee: Logback dev list Components: logback-core Created: 20/Jun/23 16:42 Priority: Major Reporter: Richard Sand Description: Similar to LOGBACK-1706, but I'm using 1.4.6 release but still encounter the issue. My configuration is unchanged, I simply changed the logback libraries from 1.2.6 to 1.4.6. My logback.xml: {{<configuration scan="true">}} {{ <insertFromJNDI env-entry-name="java:comp/env/appHome" as="appHome" />}} {{ <include file="${appHome}/conf/logback-ssorest.xml"/>}} {{ <contextListener class="ch.qos.logback.classic.jul.LevelChangePropagator"> }} {{ <resetJUL>true</resetJUL> }} {{ </contextListener> }} {{</configuration>}} ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] (LOGBACK-1717) Reduce the memory footprint with GraalVM native image
by logback developers list 19 Jun '23

19 Jun '23

1 0

[JIRA] (LOGBACK-1669) JmxConfigurator no more available in 1.4.0
by logback developers list 16 Jun '23

16 Jun '23

1 0

[JIRA] (LOGBACK-1717) Reduce the memory footprint with GraalVM native image
by logback developers list 15 Jun '23

15 Jun '23

1 0

Release of logback versions 1.3.8 and 1.4.8
by logback developers list 13 Jun '23

13 Jun '23

Hello all, I am happy to announce the simultaneous release of logback versions 1.3.8 and 1.4.8. Both versions require slf4j-api version 2.0.x or later. In addition to fixing several outstanding bugs, these releases add JsonEncoder which outputs logging events in Newline delimited JSON (ndjson) format. For more details, please refer to the the news page: http://logback.qos.ch/news.html We thank the Sovereign Tech Fund for kindly championing these releases. https://sovereigntechfund.de/en/ 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 checking out the code corresponding to the release version from github and building it, will generate a binary identical to the binary found on Maven central. 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 The Sovereign Tech Fund, 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

[JIRA] (LOGBACK-1734) Add support for NDJSON / structured logging - popular log collector/shipper format
by logback developers list 13 Jun '23

13 Jun '23

1 0

[JIRA] Updates for LOGBACK-1744: Reload logback.xml on changes to any specified properties files
by logback developers list 11 Jun '23

11 Jun '23

logback / LOGBACK-1744 [Open] Reload logback.xml on changes to any specified properties files ============================== 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-1744 ============================== Issue created ------------------------------ David M. Karr created this issue on 11/Jun/23 6:17 Summary: Reload logback.xml on changes to any specified properties files Issue Type: New Feature Assignee: Logback dev list Components: logback-core Created: 11/Jun/23 6:17 Priority: Minor Reporter: David M. Karr Description: We deploy many similar services using logback to k8s clusters. The logback.xml in each service specifies one or more properties files with a "property" element and "file" attribute. our logback.xml files specify "scan=true" and "scanPeriod=5 seconds". Our logback.xml files also "include" a "base" logback.xml that defines structures used by every service. When we dynamically modify, or just touch, either the logback.xml or the "base" logback.xml, it reloads the logback.xml and integrates any dynamic changes. However, if we instead just modify the properties file, nothing happens. It doesn't reload the logback.xml and process the new properties file content. After we modify the properties file, if we then modify the logback.xml, then it reloads everything, including the new properties file content. I asked about this situation in the logback-user list, and Ceki pretty quickly indicated that this observation is correct, but it wasn't done intentionally, it is simply an omission. He said I should file a ticket to request this, so that's what I'm doing. Logback should watch for changes to specified properties files the same way it looks for changes to the logback.xml and any other included xml files. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

what replaced StaticLoggerBinder to invoke ContextSelectorStaticBinder.init()?
by logback developers list 09 Jun '23

09 Jun '23

Before 1.3, the class StaticLoggerBinder had an init method that would in turn call the init method on the singleton ContextSelectorBinder: contextSelectorBinder.init(defaultLoggerContext, KEY); -Richard [48c29399-04ec-4cd1-8794-c7507a7d5ded]

1 6