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

[JIRA] (SLF4J-433) slf4j backend configuration errors are not fatal
by QOS.CH (JIRA) 28 Mar '18

28 Mar '18

Thorbjørn Ravn Andersen created SLF4J-433: --------------------------------------------- Summary: slf4j backend configuration errors are not fatal Key: SLF4J-433 URL: https://jira.qos.ch/browse/SLF4J-433 Project: SLF4J Issue Type: Improvement Environment: I know that a great deal of care has been put into making slf4j invisible to the application doing the logging. This includes configuration errors being transparent and all. We consider logging framework configuration errors fatal, and would like a mechanism that can tell the main application that the logging framework is broken so it can do an emergency shutdown. Our usecase is at application start up (first logging statement) but the generic case would probably be after each (re)configuration. As we by default cannot specify this through the configuration file, this probably needs to be triggered by a system property. I'd really prefer a solution which does not "know in application code" that the slf4j backend is logback. Reporter: Thorbjørn Ravn Andersen Assignee: SLF4J developers list -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 27 Mar '18

27 Mar '18

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] edlins commented on SLF4J-371: ------------------------------ +1 vote for the Supplier<T> functional interface. Either way this will be very nice addition. > Support the lambda expression in the Logger > ------------------------------------------- > > Key: SLF4J-371 > URL: https://jira.qos.ch/browse/SLF4J-371 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.7.22 > Reporter: MiNG > Assignee: SLF4J developers list > > In some cases, we don't want to calculate the expression for logging eagerly cause the performance reason. Then, we would write the code like the following: > {code:java} > if (LOGGER.isWarnEnabled()) > { > LOGGER.warn("some message: {}", Json.serialize(obj)); > }{code} > Before JDK8, there is no way to encapsulate the above code, because the expression is always calculated before passed as an argument. So, many "if"s appear in the code and smell badly. > Now, the lambda expression is supported by JDK8, the above could be simplified like following: > {code:java} > LOGGER.warn(formatter -> formatter.format("some message: {}", Json.serialize(obj)));{code} > With the default method definition in the org.slf4j.Logger: > {code:java} > public interface Logger > { > default void warn(Function<MessageFormatter, String> messageSupplier) > { > if (this.isWarnEnabled()) > { > /* Calculate the expression only if the WARN level logging is enabled. */ > this.warn(messageSupplier.apply(this.getFormatter())); > } > } > }{code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-432) log4j-over-slf4j calls wrong methods when marker parameter is null
by QOS.CH (JIRA) 26 Mar '18

26 Mar '18

Rufus created SLF4J-432: --------------------------- Summary: log4j-over-slf4j calls wrong methods when marker parameter is null Key: SLF4J-432 URL: https://jira.qos.ch/browse/SLF4J-432 Project: SLF4J Issue Type: Bug Components: log4j-over-slf4j Reporter: Rufus Assignee: SLF4J developers list Priority: Minor The org.slf4j.Logger interface has with-Marker and without-Marker versions of each logging method, e.g. public void trace(Marker marker, String format, Object arg); vs public void trace(String format, Object arg); However, the differentiatedLog method in log4j-over-slf4j ignores this and always calls the method *with* the Marker argument, even when there is no Marker. Logger implementations are then forced to defensively check for null Markers because of this error. log4j-over-slf4j should instead call the correct (without-Marker) method when there is no Marker. Patch: https://github.com/qos-ch/slf4j/pull/190/ -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-409) Logging null messages
by QOS.CH (JIRA) 22 Mar '18

22 Mar '18

[ https://jira.qos.ch/browse/SLF4J-409?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü resolved SLF4J-409. ------------------------------ Resolution: Fixed Fix Version/s: (was: 1.7.26) Fixed in [commit 3e7e72|https://github.com/qos-ch/slf4j/commit/3e7e72e70b6f3d] > Logging null messages > --------------------- > > Key: SLF4J-409 > URL: https://jira.qos.ch/browse/SLF4J-409 > Project: SLF4J > Issue Type: Bug > Components: jul-to-slf4j > Reporter: Devin Smith > Assignee: Ceki Gülcü > Priority: Minor > Fix For: 1.8.0-beta3 > > > Copied from message I sent to mailing list. > > While searching through the logging framework(s) to see why something was being logged as it was, I came across some curious code (unrelated to my issue). > > [https://github.com/qos-ch/slf4j/blob/1c6cbf05e6a99a8805397d1c06008021fdc965…] > > While the comment seems valid, `message` is an otherwise unused local variable. If the comment is still relevant, and I'm not going crazy, I'm assuming it should instead be `record.setMessage("")`? > > Cheers, > -Devin -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[qos-ch/slf4j] 5e9346: unit test SLF4J-409 and add to news.html
by Ceki Gulcu 22 Mar '18

22 Mar '18

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 5e93462dd781677fb75aefc6cc7df65822970ca0 https://github.com/qos-ch/slf4j/commit/5e93462dd781677fb75aefc6cc7df6582297… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2018-03-22 (Thu, 22 Mar 2018) Changed paths: M jul-to-slf4j/src/test/java/org/slf4j/bridge/SLF4JBridgeHandlerTest.java M slf4j-site/src/site/pages/news.html Log Message: ----------- unit test SLF4J-409 and add to news.html

1 0

[qos-ch/slf4j] 3e7e72: fix SLF4J-409
by Ceki Gulcu 22 Mar '18

22 Mar '18

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 3e7e72e70b6f3db504bda07f394e1e14832829f8 https://github.com/qos-ch/slf4j/commit/3e7e72e70b6f3db504bda07f394e1e148328… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2018-03-22 (Thu, 22 Mar 2018) Changed paths: M jul-to-slf4j/src/main/java/org/slf4j/bridge/SLF4JBridgeHandler.java Log Message: ----------- fix SLF4J-409

1 0

[JIRA] (SLF4J-407) Jigsaw modules contain clashing package
by QOS.CH (JIRA) 22 Mar '18

22 Mar '18

[ https://jira.qos.ch/browse/SLF4J-407?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü resolved SLF4J-407. ------------------------------ Resolution: Fixed Fix Version/s: (was: 1.8.0-beta3) 1.8.0-alpha2 This issue was solved in 1.8.0-alpha2 and reopened. At present time, every seems to be happy with the current approach. > Jigsaw modules contain clashing package > --------------------------------------- > > Key: SLF4J-407 > URL: https://jira.qos.ch/browse/SLF4J-407 > Project: SLF4J > Issue Type: Bug > Components: Implementations > Affects Versions: 1.8.0-alpha2 > Reporter: Stephen Colebourne > Assignee: Ceki Gülcü > Fix For: 1.8.0-alpha2 > > > Looking at the slf4j-jdk14 and slf4j-nop artifacts, they both appear to contain the package `org.slf4j.impl`. Jigsaw will refuse to load two modules that contain the same package, so this will be a problem. > I know that SLF4J does not intend users to load both of these modules at the same time. But the current setup means that it will be the JPMS runtime that rejects it, meaning that there is no chance for SLF4J to output a helpful message (as I believe it does today). > The solution to this would appear to be to move the `org.slf4j.impl` package to `org.slf4j.jul.impl` and `org.slf4j.nop.impl`. As the impl package is not exported, this should not affect any user code (except code that would have been affected anyway). > I imagine this affects other slf4j artifacts. > I also note that [this module-info.java|https://github.com/qos-ch/slf4j/blob/1_8_0-SNAPSHOT/slf4j-…] exports the `org.slf4j.jul` package, which seems unnecessary (simple and nop do not export their package). > See [here|http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html] for more information on naming. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-407) Jigsaw modules contain clashing package
by QOS.CH (JIRA) 22 Mar '18

22 Mar '18

[ https://jira.qos.ch/browse/SLF4J-407?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-407: ---------------------------------- In case there are multiple providers available on the module-path, slf4j-api, more precisely org.slf4j.LoggerFactory emits a warning message and picks up the first provider. Here is an example. {code} > java -p target/classes\;lib/slf4j-api-1.8.0-beta2.jar\;lib/slf4j-simple-1.8.0-beta2.jar\;lib/slf4j-jdk14-1.8.0-beta2.jar -m org.foo/pkg.Main SLF4J: Class path contains multiple SLF4J providers. SLF4J: Found provider [org.slf4j.simple.SimpleServiceProvider@59f99ea] SLF4J: Found provider [org.slf4j.jul.JULServiceProvider@27efef64] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. SLF4J: Actual provider is of type [org.slf4j.simple.SimpleServiceProvider@59f99ea] [main] INFO Main - hello {code} > Jigsaw modules contain clashing package > --------------------------------------- > > Key: SLF4J-407 > URL: https://jira.qos.ch/browse/SLF4J-407 > Project: SLF4J > Issue Type: Bug > Components: Implementations > Affects Versions: 1.8.0-alpha2 > Reporter: Stephen Colebourne > Assignee: Ceki Gülcü > Fix For: 1.8.0-beta3 > > > Looking at the slf4j-jdk14 and slf4j-nop artifacts, they both appear to contain the package `org.slf4j.impl`. Jigsaw will refuse to load two modules that contain the same package, so this will be a problem. > I know that SLF4J does not intend users to load both of these modules at the same time. But the current setup means that it will be the JPMS runtime that rejects it, meaning that there is no chance for SLF4J to output a helpful message (as I believe it does today). > The solution to this would appear to be to move the `org.slf4j.impl` package to `org.slf4j.jul.impl` and `org.slf4j.nop.impl`. As the impl package is not exported, this should not affect any user code (except code that would have been affected anyway). > I imagine this affects other slf4j artifacts. > I also note that [this module-info.java|https://github.com/qos-ch/slf4j/blob/1_8_0-SNAPSHOT/slf4j-…] exports the `org.slf4j.jul` package, which seems unnecessary (simple and nop do not export their package). > See [here|http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html] for more information on naming. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

MDC works with twitter scala Future but not CompletableFuture
by Dean Hiller 22 Mar '18

22 Mar '18

Has anyone requested the jdk to add Local.java to CompletableFuture.java so that context can be transferred through the .thenApply and .thenCompose methods. ie. can we make MDC work in java-land with CompletableFutures? (it works in scala land with twitter scala Future by swapping the MDC out for the below thing I describe) let me go into more detail here. We use twitter Future.scala which knows about Local.scala and Local.scala "acts" like a ThreadLocal. I say acts because when you do future.map/flatMap(in java that is thenApply/thenCompose), it transfers the threadlocal through to the next executing function. soooo, long story short, in twitter servers, I can say MDC.put("requestId", someRequestId) and it works over the .map/.flatMap. This is not possible in java!!!!! ahhhhh.... and I wrote a whole webserver in java with CompletableFutures before I found this out https://github.com/deanhiller/webpieces ps. their response was that it would be a global. Sure, but I am practical and it solves a huge many platform problems like MDC, and some in my server where I don't know the customers code(and I had to hack around not having a Local type thing available :( ). Another reason they elude to is some methods they don't know how to handle Local in those cases(yup, well scala had the same thing but it managed to implement it because it was too important and now java is behind :( ). Anyways, it would be nice if others spoke up before they realize they need it for the MDC to keep working. thanks, Dean

2 3

[qos-ch/slf4j] 1c713e: cater for JDK 10 and later
by Ceki Gulcu 22 Mar '18

22 Mar '18

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 1c713e7c1042ca1fcba550df79a4ad7fce055211 https://github.com/qos-ch/slf4j/commit/1c713e7c1042ca1fcba550df79a4ad7fce05… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2018-03-22 (Thu, 22 Mar 2018) Changed paths: M pom.xml Log Message: ----------- cater for JDK 10 and later

1 0