- logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1735) ILoggingEvent#getInstant should return `Instant.ofEpochMills(getTimeStamp())` instead of null for compatibility
by logback developers list 20 Apr '23

20 Apr '23

1 0

[JIRA] Updates for LOGBACK-1735: ILoggingEvent#getInstant should return `Instant.ofEpochMills(getTimeStamp())` instead of null for compatibility
by logback developers list 20 Apr '23

20 Apr '23

logback / LOGBACK-1735 [Open] ILoggingEvent#getInstant should return `Instant.ofEpochMills(getTimeStamp())` instead of null for compatibility ============================== 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-1735 ============================== Issue created ------------------------------ wreulicke created this issue on 20/Apr/23 4:01 Summary: ILoggingEvent#getInstant should return `Instant.ofEpochMills(getTimeStamp())` instead of null for compatibility Issue Type: Improvement Affects Versions: 1.4.8 Assignee: Logback dev list Components: logback-classic Created: 20/Apr/23 4:01 Environment: In my case, the compatibility is broken in the following conditions. - use logstash-logback-encoder 5.3 - use armeria-logback 1.23.1 - this module is compiled with logback 1.2.x - use logback 1.4.x - logback config ``` <configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder class="net.logstash.logback.encoder.LogstashEncoder" /> </appender> <appender name="RCEA" class="com.linecorp.armeria.common.logback.RequestContextExportingAppender"> <appender-ref ref="STDOUT" /> </appender> <root level="info"> <appender-ref ref="RCEA" /> </root> </configuration> ``` The logstash-logback-encoder 7.3 calls `getInstant()` when logback 1.3 or higher, [here](https://github.com/logfellow/logstash-logback-encoder/blob/logstash-l… But, armeria-logback has LoggingEventWrapper that extends logback's LoggingEvent. The LoggingEventWrapper lacks the implementation of `getInstant()` because it depends on logback 1.2 to keep compatibility. Therefore, logstash-logback-encoder are going to get `null` by default implementation of `getInstant` in ILoggingEvent. After that, logging is not working by NullPointerException. Priority: Major Reporter: wreulicke Description: `ILoggingEvent#getInstant()` is introduced in version 1.3. But, the default implementation returns null. I think this is the compatibility issue between 1.2.x ~ 1.3.x. So, to improve compatibility with 1.2 or prior, propose default implementation returns `Instant.ofEpochMills(getTimeStamp())`. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for LOGBACK-1734: Add support for NDJSON / structured logging - popular log collector/shipper format
by logback developers list 19 Apr '23

19 Apr '23

logback / LOGBACK-1734 [Open] Add support for NDJSON / structured logging - popular log collector/shipper format ============================== 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-1734 ============================== Issue created ------------------------------ Oleksandr Gavenko created this issue on 20/Apr/23 1:19 Summary: Add support for NDJSON / structured logging - popular log collector/shipper format Issue Type: Bug Assignee: Logback dev list Components: logback-classic Created: 20/Apr/23 1:19 Labels: layouts Priority: Major Reporter: Oleksandr Gavenko Description: Modern centralized logging assumes you work with structured data and even *beyond logger/message/exception* you enhance data with **MDC** (like httpUrl / httpMethod or customerEmail, etc) and with `keyValue` of SLF4J fluent API. Some tracing solution (OpenTelemetry/OpenTracing) might add additional dimension to data, via MDC, for example: https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/m… So: * logging data gets lots of independent dimensions (via MDC or keyValue) * plain text file ambiguity is no longer acceptable - who wants to deal with parsing multiline stack traces anymore? One of the popular structured format is NDJSON. http://ndjson.org/ tells that NDJSON is a file with valid JSON on each line. Popular file log collectors supports NDJSON parsers: * FluentBit https://docs.fluentbit.io/manual/pipeline/parsers/json * FileBeat (from Elastic) https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-input-files… Today to log in NDJSON format you need to relay on 3rd party layout providers, like https://github.com/logfellow/logstash-logback-encoder I with Logback has support for NDJSON out of the box. https://github.com/qos-ch/logback-contrib/blob/master/json/classic/src/main… is not a solution: * it lacks customization: possibility to rename attributes * it lacks customization: possibility to flatten MDC * it lacks support for Markers * it lacks support for keyValue of fluent API * it lacks support for nanoseconds * it lacks auto-incremented sequence number - centralized logging solutions store events in random order, if a query returns several events withing millisecond (or nanosecond) - they will be presented in random order, not the original order! ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] (LOGBACK-1733) The size of the thread pool for ScheduledExecutor should be ajustable
by logback developers list 19 Apr '23

19 Apr '23

1 0

[JIRA] (LOGBACK-1716) ServerSocketAppender doesn't work with 1.3.0+
by logback developers list 19 Apr '23

19 Apr '23

1 0

[JIRA] (LOGBACK-1733) The size of the thread pool for ScheduledExecutor should be ajustable
by logback developers list 19 Apr '23

19 Apr '23

1 0

[JIRA] Updates for LOGBACK-1733: The size of the thread pool for ScheduledExecutor should be ajustable
by logback developers list 18 Apr '23

18 Apr '23

logback / LOGBACK-1733 [Open] The size of the thread pool for ScheduledExecutor should be ajustable ============================== Here's what changed in this issue in the last few minutes. This issue has been created View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1733 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 18/Apr/23 14:24 Summary: The size of the thread pool for ScheduledExecutor should be ajustable Issue Type: Sub-task Affects Versions: 1.3.6, 1.4.6 Assignee: Ceki Gülcü Created: 18/Apr/23 14:24 Fix Versions: 1.3.7, 1.4.7 Priority: Major Reporter: Ceki Gülcü ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] (LOGBACK-1716) ServerSocketAppender doesn't work with 1.3.0+
by logback developers list 17 Apr '23

17 Apr '23

1 0

[JIRA] (LOGBACK-1716) ServerSocketAppender doesn't work with 1.3.0+
by logback developers list 16 Apr '23

16 Apr '23

1 0

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

04 Apr '23

1 0