June 2023 - logback-dev - mailman3.qos.ch

[JIRA] Updates for LOGBACK-1748: JsonEncoder: allow configuring to get formatted message in the json payload
by logback developers list 21 Jun '23

21 Jun '23

logback / LOGBACK-1748 [Open] JsonEncoder: allow configuring to get formatted message in the json payload ============================== 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-1748 ============================== Issue created ------------------------------ Bruno Ballekens created this issue on 21/Jun/23 17:08 Summary: JsonEncoder: allow configuring to get formatted message in the json payload Issue Type: Improvement Affects Versions: 1.4.8 Assignee: Logback dev list Components: logback-classic Created: 21/Jun/23 17:08 Priority: Major Reporter: Bruno Ballekens Description: JsonEncoder currently does not put the formatted message in the json payload. It puts the message and the argument array. Some of the libs we use, do log using the message format based methods, which now look strange in our log aggregation system (sometimes we even see {} as the message with then the actual message as the single member of the argument array). Would it be possible to make JsonEncoder configurable to put the formatted message in the json payload with `message` key ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

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

21 Jun '23

1 0

[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