- slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-434) Suggestion: Additional simplelogger.properties file
by QOS.CH (JIRA) 17 Apr '18

17 Apr '18

Joachim Durchholz created SLF4J-434: --------------------------------------- Summary: Suggestion: Additional simplelogger.properties file Key: SLF4J-434 URL: https://jira.qos.ch/browse/SLF4J-434 Project: SLF4J Issue Type: Improvement Environment: Allow an additional simplelogger.properties file. Use case: We have a simplelogger.properties in the git-managed source tree. However, we also want to have a .gitignored properties file so we can do quick local testing. Suggestion: Add configuration directive org.slf4j.simpleLogger.configFile. Includes the file, overriding the settings from the source that the configFile directive was in (simplelogger.properties or system properties, whichever may be the case). The included file must not contain another configFile directive. My status: Discussion welcome. Willing to contribute patch if so desired. Reporter: Joachim Durchholz Assignee: SLF4J developers list Priority: Minor -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-422) Have slf4j-log4j12 include extra arguments to Logger methods
by QOS.CH (JIRA) 13 Apr '18

13 Apr '18

[ https://jira.qos.ch/browse/SLF4J-422?page=com.atlassian.jira.plugin.system.… ] Eric Pabst commented on SLF4J-422: ---------------------------------- This hasn't gotten ANY attention for over 4 months! It looks like Log4J 2 doesn't have this issue at all, so it looks like it's worth switching frameworks. Its MapMessage does what I need, and JSON is directly supported rather than separate in logstash. > Have slf4j-log4j12 include extra arguments to Logger methods > ------------------------------------------------------------ > > Key: SLF4J-422 > URL: https://jira.qos.ch/browse/SLF4J-422 > Project: SLF4J > Issue Type: Improvement > Components: Implementations > Affects Versions: 1.7.22 > Environment: All > Reporter: Eric Pabst > Assignee: SLF4J developers list > > The purpose of logging to slf4j is to allow code to log information without worrying about which implementation and format will be used for actual logging. In deployed environments, we prefer JSON logging using logstash to be consumed by Splunk, which handles JSON very nicely. However, for local development and testing, we prefer text output via log4j or logback-classic. > We often want to log extra fields to show up in the JSON output such as > {{\{ "timestamp": "2017...", "message": "Event X happened", "userName": "bob", "url": "http://..."}}} > To accomplish this, we use logstash's StructuredArgument to provide extra arguments to the Logger: > {{import static net.logstash.logback.argument.StructuredArguments.keyValue;}} > {{...}} > {{ LOGGER.info("Event X happened", keyValue("userName", "bob"), keyValue("url", "http://..."));}} > We don't want to include \{}'s in the message or else it would log the username and url both in the message and as separate JSON properties. > However, when binding to slf4j-log4j12, it is logged without these extra arguments: > {{INFO 2017... Event X happened}} > It would help immensely to include these extra arguments automatically if present: > INFO 2017... Event X happened username=bob url=http://... -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 11 Early Access build 8 available
by Rory O'Donnell 12 Apr '18

12 Apr '18

Hi Ceki, **JDK 11 EA build 8, *****under both the GPL and Oracle EA licenses, is now available at **http://jdk.java.net/11**. ** * * Newly approved Schedule, status & features o http://openjdk.java.net/projects/jdk/11/ * Release Notes: o http://jdk.java.net/11/release-notes * Summary of changes o https://download.java.net/java/early_access/jdk11/8/jdk-11+8.html *Notable changes in JDK 11 EA builds since last email:* * Build 8: o If you have a library that uses the Selector API heavily then now would be a good time to test it out. [1] * Build 7 o The VM option "-XX:+AggressiveOpts" is deprecated in JDK 11 and will be removed in a future release. * Build 6: o JDK-8193033 : remove terminally deprecated sun.misc.Unsafe.defineClass. Users should use the public replacement `java.lang.invoke.MethodHandles.Lookup.defineClass` which was added in Java SE 9. [2] ** *SURVEY: The HotSpot Serviceability Agent (SA) *[3] * If you have used, or have (support) processes that utilize the Serviceability Agent or related APIs, then we would definitely appreciate if you would complete this survey: https://www.surveymonkey.com/r/CF3MYDL Regards, Rory [1] http://mail.openjdk.java.net/pipermail/nio-dev/2018-April/004964.html [2] https://docs.oracle.com/javase/9/docs/api/java/lang/invoke/MethodHandles.Lo… [3] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001052.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[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