March 2022 - slf4j-dev - mailman3.qos.ch

[JIRA] Updates for SLF4J-526: Idea for fluent API improvement
by QOS.CH (JIRA) 22 Mar '22

22 Mar '22

SLF4J / SLF4J-526 [Open] Idea for fluent API improvement ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-526 ============================== 1 comment ------------------------------ Adrian Shum on 22/Mar/22 12:53 AM @ceki+jira Great to know! :) some other ideas for the initial proposal, which I dunno if make sense: * By default, return a thread-local instance of builder which can ** reduce cost of allocating new one every time ** could provide detection of missing log(), by checking if builder.log() has been called at atXxx() ** Although above should serve 99.9% of use case, if someone really need a separate instance of builder (e.g. they are building up multiple log messages at the same time), we could provide an extra atXxx() method which will return new instance * It may make sense to allow providing message/messageProvider at the atXxx() method directly. So to demonstrate the idea: {code:java} ////////////////////////////////////////////////////////////////////// // reduced builder allocation ////////////////////////////////////////////////////////////////////// logger.atDebug().message("first log {}").arg(a1).log(); // returning a thread local instance of builder logger.atDebug().message("second log {}").arg(a2).log(); // the builder instance we use here will be the same as above logger.atDebug().message("forgot to call log()"); logger.atDebug().message("fourth log{}").log(); // when we call atDebug(), it check if the builder is "clear". If not, give a warning or automatically call the log()? ////////////////////////////////////////////////////////////////////// // if people really wants to have multiple instances of builder ////////////////////////////////////////////////////////////////////// outputBuilder = logger.atDebug(AllocationType::NEW); // default one is SINGLETON maybe, which means single one per-thread errorBuilder = logger.atDebug(AllocationType::NEW); // bunch of logic to construct log by outputBuilder and errorBuilder outputBuilder.log(); errorBuilder.log(); (of course, user will not enjoy the auto-detection of missing log()) ////////////////////////////////////////////////////////////////////// // we could provide message directly ////////////////////////////////////////////////////////////////////// logger.atDebug("temperature is {}").arg(temperature).log(); {code} ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-526: Idea for fluent API improvement
by QOS.CH (JIRA) 18 Mar '22

18 Mar '22

SLF4J / SLF4J-526 [Open] Idea for fluent API improvement ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-526 ============================== 1 comment ------------------------------ Ceki Gülcü on 18/Mar/22 3:14 PM [~adrianshum] Thank you for the PR. I am quite interested in implementing your initial proposal and have [asked for feedback|http://mailman.qos.ch/pipermail/slf4j-dev/2022-March/005825.html] on the slf4j-dev@ mailing list. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-545: slf4j-jdk-platform-logging - SLF4JPlatformLogger should use java.text.MessageFormat - not String.format()
by QOS.CH (JIRA) 18 Mar '22

18 Mar '22

SLF4J / SLF4J-545 [Resolved] slf4j-jdk-platform-logging - SLF4JPlatformLogger should use java.text.MessageFormat - not String.format() ============================== Here's what changed in this issue in the last few minutes. There are 2 updates, 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-545 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 18/Mar/22 2:59 PM Resolution: Duplicate Status: Resolved (was: Open) ============================== 1 comment ------------------------------ Ceki Gülcü on 18/Mar/22 2:59 PM Duplicate of SLF4J-529 ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

Planned/possible fluent API change
by Ceki Gülcü 18 Mar '22

18 Mar '22

Hello all, In SLF4J-526, Adrian Shum proposed to modify the fluent API. Currently, to emit a debug message with two parameters, one has to write the following logger.atDebug() .addArgument(country).addArgument(oldTemp).addArgument(newTemp) .log("Temperature of {} rise from {} to {}"); He proposes that the API be changed to logger.atDebug() .message("Temperature of {} rise from {} to {}" ) .arg(country).arg(oldTemp).arg(newTemp).log(); I think his suggestion makes sense with one inconvenience. In case the user forgets to call the no-argument log() method, then nothing will happen, i.e. no logging will occur. With the current API, it is harder for the user to forget the log(String) method containing the message content. Before going forward with Adrian's proposal or not, I would like to receive input by interested parties. Best regards, [1] https://jira.qos.ch/browse/SLF4J-526 -- Ceki Gülcü

1 0

[JIRA] Updates for SLF4J-545: lf4j-jdk-platform-logging - SLF4JPlatformLogger should use java.text.MessageFormat - not String.format()
by QOS.CH (JIRA) 18 Mar '22

18 Mar '22

SLF4J / SLF4J-545 [Open] lf4j-jdk-platform-logging - SLF4JPlatformLogger should use java.text.MessageFormat - not String.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/SLF4J-545 ============================== Issue created ------------------------------ robin created this issue on 18/Mar/22 5:39 AM Summary: lf4j-jdk-platform-logging - SLF4JPlatformLogger should use java.text.MessageFormat - not String.format() Issue Type: Bug Assignee: SLF4J developers list Created: 18/Mar/22 5:39 AM Environment: Component: slf4j-jdk-platform-logging Priority: Major Reporter: robin Description: This line here: [https://github.com/qos-ch/slf4j/blob/master/slf4j-jdk-platform-logging/src/…] {{message = String.format(message, params);}} Should instead be: {{message = MessageFormat.format(message, params);}} Such that is matches the expected format of System.Logger.log() ... as per https://docs.oracle.com/javase/9/docs/api/java/lang/System.Logger.html#log-… ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-511: DefaultLogEventBuilder causes incorrect location information to be logged
by QOS.CH (JIRA) 17 Mar '22

17 Mar '22

SLF4J / SLF4J-511 [Reopened] DefaultLogEventBuilder causes incorrect location information to be logged ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-511 ============================== 1 comment ------------------------------ Ceki Gülcü on 17/Mar/22 8:50 PM [~rgoers(a)apache.org] Please let me know if 2.0.0-alpha7 fixes the issue. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-511: DefaultLogEventBuilder causes incorrect location information to be logged
by QOS.CH (JIRA) 09 Mar '22

09 Mar '22

SLF4J / SLF4J-511 [Reopened] DefaultLogEventBuilder causes incorrect location information to be logged ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-511 ============================== 1 comment ------------------------------ Ceki Gülcü on 09/Mar/22 11:43 PM I forgot to mention the {{CallerBoundaryAware}} interface which {{DefaultLoggingEventBuilder}} implements. {{CallerBoundaryAware}} interface comes with a single method, namely {{setCallerBoundary(String fqcn)}}. The {{DefaultLoggingEvent}} class has a {{setCallerBoundary}} method and more importantly the {{org.sflf4j.event.LoggerEvent}} class includes a {{getCallerBoundary}} method. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-544: LoggerFactory only loads services from context class loader
by QOS.CH (JIRA) 04 Mar '22

04 Mar '22

SLF4J / SLF4J-544 [Open] LoggerFactory only loads services from context class loader ============================== 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/SLF4J-544 ============================== Issue created ------------------------------ Tobias Hotz created this issue on 04/Mar/22 3:25 PM Summary: LoggerFactory only loads services from context class loader Issue Type: Bug Affects Versions: 1.8.0-beta4, 2.0.0-alpha6 Assignee: SLF4J developers list Components: Core API Created: 04/Mar/22 3:25 PM Priority: Minor Reporter: Tobias Hotz Description: SLF4J currently uses services loader to find a implementation to bind (See [https://github.com/ichttt/slf4j/blob/74ccf20fab1a35243ae41c2f56f2167e86afbd…]) This can cause issues with certain module classloading setups where the context classloader does not contain any module that has a slf4j implementation, but the classloader of the LoggerFactory class might be different from the context classloader and contain a module that has a slf4j implementation. My suggestion would be to expand findServiceProviders so it also class ServiceLoader.load with the class loader of LoggerFactory (if it is different from the context classloader) and add this to the list as well. This would not change existing behaviour if an implementation can be found with the context classloader, as slf4j always uses the first entry in the list returned by LoggerFactory.findServiceProviders. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0