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

[JIRA] (LOGBACK-1736) Make OSGi service-loader requirement for spi.Configurator optional
by logback developers list 25 Apr '23

25 Apr '23

1 0

[JIRA] Updates for LOGBACK-1736: Make OSGi service-loader requirement for spi.Configurator optional
by logback developers list 25 Apr '23

25 Apr '23

logback / LOGBACK-1736 [Open] Make OSGi service-loader requirement for spi.Configurator optional ============================== 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-1736 ============================== Issue created ------------------------------ Hannes Wellmann created this issue on 25/Apr/23 18:02 Summary: Make OSGi service-loader requirement for spi.Configurator optional Issue Type: Sub-task Affects Versions: 1.3.7, 1.4.7 Assignee: Logback dev list Components: logback-classic Created: 25/Apr/23 18:02 Priority: Critical Reporter: Hannes Wellmann Description: For LOGBACK-1729 the OSGi Service Loader Mediator Manifest entries were enhanced to be able to load logback {{Configurator}} services provided by other OSGi bundles. Unintentionally this requirement was only specified with {{cardinality:=multiple}} and without {{{}resolution:=optional{}}}, which means that at least one bundle providing a {{Configurator}} service is required (but multiple are possible). But having no provided {{Configurator}} at all is also a valid scenario and the code is prepared for that. Therefore the corresponding Service Loader Mediator requirement should be marked as optional ({{{}resolution:=optional{}}}) in order to allow zero up to arbitrary many provided {{Configurator}} services{{{}.{}}} ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

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

20 Apr '23

1 0

[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