August 2022 - logback-dev - mailman3.qos.ch

[JIRA] Updates for LOGBACK-1661: Incorrect javadoc description for ILoggingEvent#getNanoseconds()
by QOS.CH (JIRA) 15 Aug '22

15 Aug '22

logback / LOGBACK-1661 [Open] Incorrect javadoc description for ILoggingEvent#getNanoseconds() ============================== 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-1661 ============================== Issue created ------------------------------ Bertrand Renuart created this issue on 15/Aug/22 11:10 PM Summary: Incorrect javadoc description for ILoggingEvent#getNanoseconds() Issue Type: Bug Affects Versions: 1.3.0-beta0 Assignee: Logback dev list Components: logback-classic Created: 15/Aug/22 11:10 PM Priority: Major Reporter: Bertrand Renuart Description: The javadoc for [ILoggingEvent#getNanoseconds()|https://github.com/qos-ch/logback/blob/maste…] says: {noformat} @return the number of elapsed nanoseconds since epoch{noformat} The default implementation simply returns the result of calling Instant#getNano(). However this method returns _the number of nanoseconds, later along the time-line, *from the start of the +second+* - and not since +_epoch+_._ There seems to be a mismatch between the javadoc and the default implementation provided by the interface. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] (LOGBACK-1660) Please add SyslogAppender that can connect to a unix socket
by QOS.CH (JIRA) 15 Aug '22

15 Aug '22

1 0

[JIRA] Updates for LOGBACK-1660: Please add SyslogAppender that can connect to a unix socket
by QOS.CH (JIRA) 15 Aug '22

15 Aug '22

logback / LOGBACK-1660 [Open] Please add SyslogAppender that can connect to a unix socket ============================== 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-1660 ============================== Issue created ------------------------------ Gary van der Merwe created this issue on 15/Aug/22 7:13 PM Summary: Please add SyslogAppender that can connect to a unix socket Issue Type: New Feature Assignee: Logback dev list Components: logback-classic Created: 15/Aug/22 7:13 PM Priority: Major Reporter: Gary van der Merwe Description: Please add SyslogAppender that can connect to a unix socket. I would like to be able to send structured log to systemd-journald I know there are 3rd party libraries to do this, but they are almost impossible to use with [Tomcat-Slf4j-Logback|https://github.com/tomcat-slf4j-logback/tomcat-slf4j-l…] ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for LOGBACK-1659: Unnecessary OffsetDateTime creation in CachingDateFormat
by QOS.CH (JIRA) 13 Aug '22

13 Aug '22

logback / LOGBACK-1659 [Open] Unnecessary OffsetDateTime creation in CachingDateFormat ============================== 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-1659 ============================== Issue created ------------------------------ Bertrand Renuart created this issue on 13/Aug/22 4:27 PM Summary: Unnecessary OffsetDateTime creation in CachingDateFormat Issue Type: Improvement Affects Versions: 1.3.0-beta0 Assignee: Logback dev list Components: logback-core Created: 13/Aug/22 4:27 PM Priority: Major Reporter: Bertrand Renuart Description: CachingDateFormat creates a temporary OffsetDateTime from the given instant to apply the configured time zone (see [here|https://github.com/qos-ch/logback/blob/master/logback-core/src/main/ja…] before passing it to the DateTimeFormatter for rendering. This temporary OffsetDateTime can be avoided by setting the ZoneId directly on the DateTimeFormatter when it is initialized. This is apparently what was foreseen in the constructor with the following [lines|https://github.com/qos-ch/logback/blob/master/logback-core/src/main/j…] {code:java} public CachingDateFormatter(String pattern, ZoneId aZoneId) { dtf = DateTimeFormatter.ofPattern(pattern); ... dtf.withZone(this.zoneId); ... }{code} Unfortunately this won't work because "{{withZone()}}" returns a new formatter which is not assigned to the "{{dtf}}" instance variable... *To summarise:* (1) In the constructor do something like: {code:java} dtf = DateTimeFormatter.ofPattern(pattern).withZone(this.zoneId) {code} (2) In the "format()" method do something like: {code:java} Instant instant = Instant.ofEpochMilli(now); String result = dtf.format(instant); {code} --> no need for an intermediate OffsetDateTime anymore ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for LOGBACK-1658: LayoutPattern does not support nanoseconds format
by QOS.CH (JIRA) 13 Aug '22

13 Aug '22

logback / LOGBACK-1658 [Open] LayoutPattern does not support nanoseconds 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-1658 ============================== Issue created ------------------------------ Bertrand Renuart created this issue on 13/Aug/22 4:11 PM Summary: LayoutPattern does not support nanoseconds format Issue Type: Bug Affects Versions: 1.3.0-beta0 Assignee: Logback dev list Components: logback-classic Created: 13/Aug/22 4:11 PM Environment: PatternLayout trims the event timestamp down to milliseconds precision irrespective of the configured pattern. For instance the following config: {code:java} <appender name="LOGBACK" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%date{dd-MM-yyyy'T'HH:mm:ss.n} - %msg%n</pattern> </encoder> </appender> {code} produces output like the following: {code:java} 13-08-2022T16:05:49.211000000 - A sample log message (0) 13-08-2022T16:05:49.213000000 - A sample log message (1) 13-08-2022T16:05:49.213000000 - A sample log message (2) 13-08-2022T16:05:49.213000000 - A sample log message (3) 13-08-2022T16:05:49.213000000 - A sample log message (4) 13-08-2022T16:05:49.213000000 - A sample log message (5){code} As you can see although the pattern asks for nanoseconds after the seconds only the millis are actually output with the nano parts set to zero. A quick look at the code reveals that the {{DateConverter}} gets the timestamp from the ILoggingEvent by calling {{ILoggingEvent#getTimeStamp()}} which gives the timestamp in millis instead of the new {{ILoggingEvent#getInstant()}}. See [https://github.com/qos-ch/logback/blob/master/logback-classic/src/main/java…] Priority: Major Reporter: Bertrand Renuart ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] (LOGBACK-1656) Unused "nanoseconds" field in LoggingEvent
by QOS.CH (JIRA) 13 Aug '22

13 Aug '22

1 0

[JIRA] Updates for LOGBACK-1657: LoggingEventV0 is loosing the nanoseconds
by QOS.CH (JIRA) 13 Aug '22

13 Aug '22

logback / LOGBACK-1657 [Open] LoggingEventV0 is loosing the nanoseconds ============================== 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-1657 ============================== Issue created ------------------------------ Bertrand Renuart created this issue on 13/Aug/22 12:14 PM Summary: LoggingEventV0 is loosing the nanoseconds Issue Type: Bug Affects Versions: 1.3.0-beta0 Assignee: Logback dev list Components: logback-classic Created: 13/Aug/22 12:14 PM Environment: LoggingEventV0 stores the event timestamp as a long with mills precision. It therefore looses the nanoseconds precision from the original LoggingEvent. Instead it should rather get and store the Instant from the original ILoggingEvent and (if needed) derive the millis from it. Also, it doesn't implement the getInstant() method inherited from the ILoggingEvent interface and therefore inherits the default implementation which returns null. This may be rather confusing when the original event was initialised with an Instant. Priority: Major Reporter: Bertrand Renuart ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for LOGBACK-1656: Unused "nanoseconds" field in LoggingEvent
by QOS.CH (JIRA) 13 Aug '22

13 Aug '22

logback / LOGBACK-1656 [Open] Unused "nanoseconds" field in LoggingEvent ============================== 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-1656 ============================== Issue created ------------------------------ Bertrand Renuart created this issue on 13/Aug/22 10:43 AM Summary: Unused "nanoseconds" field in LoggingEvent Issue Type: Improvement Affects Versions: 1.3.0-beta0 Assignee: Logback dev list Components: logback-classic Created: 13/Aug/22 10:43 AM Priority: Minor Reporter: Bertrand Renuart Description: I noticed {{LoggingEvent}} contains an unused {{nanoseconds}} member field that could probably be removed. See https://github.com/qos-ch/logback/blob/master/logback-classic/src/main/java… ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for LOGBACK-1655: Allow a standard way of stacking/finding configurators
by QOS.CH (JIRA) 10 Aug '22

10 Aug '22

logback / LOGBACK-1655 [Open] Allow a standard way of stacking/finding configurators ============================== 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-1655 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 10/Aug/22 6:45 PM Summary: Allow a standard way of stacking/finding configurators Issue Type: Bug Affects Versions: 1.3.0-beta0 Assignee: Ceki Gülcü Created: 10/Aug/22 6:45 PM Fix Versions: 1.3.0 Priority: Major Reporter: Ceki Gülcü Description: Assuming more logback configurators will be written, it behooves logback-classic to support stacking of configurators. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for LOGBACK-1654: More advanced filtering stacktrace lines
by QOS.CH (JIRA) 10 Aug '22

10 Aug '22

logback / LOGBACK-1654 [Open] More advanced filtering stacktrace lines ============================== 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-1654 ============================== Issue created ------------------------------ Grzegorz Borkowski created this issue on 10/Aug/22 3:33 PM Summary: More advanced filtering stacktrace lines Issue Type: Improvement Assignee: Logback dev list Created: 10/Aug/22 3:33 PM Priority: Major Reporter: Grzegorz Borkowski Description: Currently, logback allows excluding some of the lines in the stacktraces from printing, which is useful for hiding stack frames coming from frameworks. E.g. {{%rEx{full,}} {{ java.lang.reflect.Method,}} {{org.springframework,}} {{ sun.reflect,}} {{ net.sf.cglib,}} {{ ByCGLIB}} {{ }}} But sometimes a bit more advanced filtering would be useful. For example, we're using javalin web framework. In recent versions they refactored their code and now the stack trace from the framework contains lots of java.util.concurrent.CompletableFuture.xxx frames. If I just filter out all CompletableFuture calls, i risk hiding them also from my own code that can use CompletableFuture. This would be very confusing. So i think it would be nice to be able to configure a custom "stacktracefilter" implementation that would be smart and could contain mode adanced logic. For example, it would scan the frames until it finds the first line from the framework (io.javalin.Xxx in my case) and only then starts filtering the CompletableFuture lines. This could look like this: {{<configuration>}} {{ <stackTraceFrameEvaluator name="MY_EVAL" class="my.stackTraceFrameEvaluator"/>}} {{<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> }} {{ <encoder>}} {{ <pattern>}} {{ %msg%rEx\{MY_EVAL}}} {{ </pattern>}} {{ </encoder>}} {{ </appender>}} {{</configuration>}} ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0