- slf4j-dev - mailman3.qos.ch

PR merge?
by Doug Roper 06 Jan '18

06 Jan '18

Hey slf4j devs, I opened https://github.com/qos-ch/slf4j/pull/177 seven months ago to fix two bugs I found in EventRecodingLogger. It's a 2-line change to src/main/java. The rest is src/test/java junit coverage. https://github.com/qos-ch/slf4j#how-to-contribute-pull-requests seems to indicate that you welcome pull requests. I've followed the process and created a tracking ticket https://jira.qos.ch/browse/SLF4J-411 as well. I've been a fan of slf4j and logback for a long time, but the radio silence has been disappointing for me. I've bumped both the PR and jira ticket, but haven't heard any communication from this group. Is there something else I should be doing to have this change accepted? --Doug

1 0

[JIRA] (SLF4J-425) stack trace is logged despite exception matching a parameter in format string
by QOS.CH (JIRA) 02 Jan '18

02 Jan '18

Dan Lipofsky created SLF4J-425: ---------------------------------- Summary: stack trace is logged despite exception matching a parameter in format string Key: SLF4J-425 URL: https://jira.qos.ch/browse/SLF4J-425 Project: SLF4J Issue Type: Bug Components: Core API Affects Versions: 1.7.25 Environment: Slf4j 1.7.25 Logback 1.2.3 SpringBoot 1.5.9 Java 1.8.0_121 Reporter: Dan Lipofsky Assignee: SLF4J developers list Priority: Minor I want to pass an exception into a parameterized log call and have it *not* log the stacktrace. According to the [FAQ|https://www.slf4j.org/faq.html#paramException] "If the exception is not the last argument, it will be treated as a plain object and its stack trace will NOT be printed." which is exactly what I want. {{But when I try}} {{LOG.info("foo \{} bar \{}", "xxx", new RuntimeException("ZZZ"));}} {{I get}} {{2018-01-02 15:52:40.637 INFO [main] com.foo.Bar foo xxx bar \{}}} {{java.lang.RuntimeException: ZZZ}} {{ at com.foo.Bar.<init>(Bar.java:37)}} {{ ...}} so it does not substitute that last parameter and it creates an unwanted stacktrace. I can work around this by manually calling toString() but this * defeats the efficiencies of using a parameterized call * probably makes my static analysis tool warn that the exception has not been logged -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

Location of SLF4J-Android Binding?
by Patrick Favre 31 Dec '17

31 Dec '17

I found a bug in the implementation while writing unit tests for a Timber binding, found in https://mvnrepository.com/artifact/org.slf4j/slf4j-android/1.7.25 (which also seems to be propagated into many forks of this impl). The bug is: AndroidLoggerAdapter:253 /** * Log an exception (throwable) at level DEBUG with an accompanying message. * * @param msg * the message accompanying the exception * @param t * the exception (throwable) to log */ public void debug(String msg, Throwable t) { log(Log.VERBOSE, msg, t); } -> debug log, logs with VERBOSE priority. I am more than happy to provide a PR, but I can't seem to find the location of the "official" Android implementation. could somebody please tell me where to find it? lg pf

1 0

[JIRA] (SLF4J-411) EventRecodingLogger.debug(String) logs at TRACE
by QOS.CH (JIRA) 26 Dec '17

26 Dec '17

[ https://jira.qos.ch/browse/SLF4J-411?page=com.atlassian.jira.plugin.system.… ] Doug Roper commented on SLF4J-411: ---------------------------------- Hi Ceki, I'm looking to close out my old PRs by the end of the year. Have you had time to review [https://github.com/qos-ch/slf4j/pull/177]? EventRecodingLogger is quite useful for unit tests. Merging the bugfix would allow me remove some duplicate implementations from my own projects. Also, it would be an honor to be contributor to something as widely used as slf4j. Thanks! > EventRecodingLogger.debug(String) logs at TRACE > ----------------------------------------------- > > Key: SLF4J-411 > URL: https://jira.qos.ch/browse/SLF4J-411 > Project: SLF4J > Issue Type: Bug > Affects Versions: 1.8.0-alpha2 > Reporter: Doug Roper > Assignee: Ceki Gülcü > Priority: Minor > Fix For: 1.7.26, 1.8.0-beta1 > > > [https://github.com/qos-ch/slf4j/blob/v_1.8.0-alpha2/slf4j-api/src/main/java…] > {code:java} > public void debug(String msg) { > recordEvent(Level.TRACE, msg, null, null); > } > {code} > Expected result: debug method logs at debug. > Actual result: debug method logs at trace. > Seems like a copy-paste bug. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 10 entered Rampdown Phase One on 14th of December
by Rory O'Donnell 18 Dec '17

18 Dec '17

Hi Ceki, *JDK 10 entered Rampdown Phase One on Thursday, 14 December [1] * * The Rampdown Phase One process will be similar to that of JDK 9 [2]. *JDK 10 Early Access build 36 is available at : - jdk.java.net/10/* Notable changes since previous email. *JEPS included **the last 3 builds:* JDK-8192833 <https://bugs.openjdk.java.net/browse/JDK-8192833> :This is the primary implementation subtask of JEP 322 - *Time-Based Release Versioning* JDK-8189941 <https://bugs.openjdk.java.net/browse/JDK-8189941> : Implementation JEP 312: Thread-local handshake JDK-8186571 <https://bugs.openjdk.java.net/browse/JDK-8186571> : Implementation: JEP 307: Parallel Full GC for G1 JDK-8190308 <https://bugs.openjdk.java.net/browse/JDK-8190308> : Implementation: JEP 316: Heap Allocation on Alternative Memory Devices *build 36 *JDK-8148421 <https://bugs.openjdk.java.net/browse/JDK-8148421> : Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension JDK-5016517 <https://bugs.openjdk.java.net/browse/JDK-5016517> : Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent ** *build 35 * JDK-8188870 <https://bugs.openjdk.java.net/browse/JDK-8188870> - Bump classfile version number to 54 JDK-8185985 <http://bugs.openjdk.java.net/browse/JDK-8185985> - HTML files in doc-files subdirectories are wrapped with standard javadoc decorations JDK-8186535 <http://bugs.openjdk.java.net/browse/JDK-8186535>*- *Remove deprecated pre-1.2 SecurityManager methods and fields *build 34* - JDK-8024352 <http://bugs.openjdk.java.net/browse/JDK-8024352> - MBeanOperationInfo accepts any int value as "impact" *Bug fixes reported by Open Source Projects :*<https://bugs.openjdk.java.net/browse/JDK-8191834> JDK-8191078 <https://bugs.openjdk.java.net/browse/JDK-8191078> : Wrong "Package not found" warning JDK-8191636 <https://bugs.openjdk.java.net/browse/JDK-8191636> : [Windows] jshell tool: Wrong character in /env class-path command crashes jshell JDK-8191834 <https://bugs.openjdk.java.net/browse/JDK-8191834> : Assigning a void expression to a "var" crashes the compiler<https://bugs.openjdk.java.net/browse/JDK-8182638> JDK-8182638 <https://bugs.openjdk.java.net/browse/JDK-8182638> : [macosx] Active modal dialog is hidden by another non-active one JDK-8043315 <https://bugs.openjdk.java.net/browse/JDK-8043315> : Nimbus: Setting Nimbus.Overrides property affects custom keymap installation JDK-8172244 <https://bugs.openjdk.java.net/browse/JDK-8172244> : AIOOBE in KeyStore.getCertificateAlias on Windows JDK-8180141 <https://bugs.openjdk.java.net/browse/JDK-8180141> : Missing entry in LineNumberTable for break statement that jumps out of try-finall JDK 10 Schedule, Status & Features are available [3] *Feedback* - If you have suggestions or encounter bugs, please submit them using the usual Java SE bug-reporting channel. Be sure to include complete version information from the output of the |java --version| command. Regards, Rory [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-December/000357.html [2] http://openjdk.java.net/projects/jdk9/rdp-1 [3] http://openjdk.java.net/projects/jdk/10/ -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[qos-ch/slf4j] 0b1e6d: fix mailman urls
by Ceki Gulcu 16 Dec '17

16 Dec '17

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 0b1e6d38cfabd4b7ed335aec1aa6b2ae0c770f08 https://github.com/qos-ch/slf4j/commit/0b1e6d38cfabd4b7ed335aec1aa6b2ae0c77… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2017-12-16 (Sat, 16 Dec 2017) Changed paths: M slf4j-site/src/site/pages/mailing-lists.html Log Message: ----------- fix mailman urls

1 0

[JIRA] (SLF4J-422) Have slf4j-log4j12 include extra arguments to Logger methods
by QOS.CH (JIRA) 12 Dec '17

12 Dec '17

[ https://jira.qos.ch/browse/SLF4J-422?page=com.atlassian.jira.plugin.system.… ] Eric Pabst commented on SLF4J-422: ---------------------------------- I found a thread related to this in the slf4j-users mailing list: http://markmail.org/message/2tpe4ruwriokzxc5 > 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

[JIRA] (SLF4J-420) Make a release with Automatic-Module-Name
by QOS.CH (JIRA) 12 Dec '17

12 Dec '17

[ https://jira.qos.ch/browse/SLF4J-420?page=com.atlassian.jira.plugin.system.… ] Stephen Colebourne commented on SLF4J-420: ------------------------------------------ See https://github.com/qos-ch/slf4j/pull/184 > Make a release with Automatic-Module-Name > ----------------------------------------- > > Key: SLF4J-420 > URL: https://jira.qos.ch/browse/SLF4J-420 > Project: SLF4J > Issue Type: Task > Reporter: Gael Lalire > Assignee: SLF4J developers list > Priority: Trivial > > You can make a release with Automatic-Module-Name with 1.7 version so it can load logback and have the package name you choose in 1.8 beta. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-424) extend "Logger" with fluent API to simplify logging calls with additional information (via MDC)
by QOS.CH (JIRA) 11 Dec '17

11 Dec '17

Christian Lorenz created SLF4J-424: -------------------------------------- Summary: extend "Logger" with fluent API to simplify logging calls with additional information (via MDC) Key: SLF4J-424 URL: https://jira.qos.ch/browse/SLF4J-424 Project: SLF4J Issue Type: Improvement Components: Core API Reporter: Christian Lorenz Assignee: SLF4J developers list Hi, In our project we use SLF4J with Logback and logstash-logback-encoder. To use the advantages of ELK (Logstash) we set fields via MDC within the processing flow, but sometimes we also want to create custom fields (by using MDC) just for a single log message. Unfortunately the SLF4J Logger API does not provide a easy way to do that. To improve the API I've started implementing a fluent API to log messages. [https://github.com/jackhammer2k/slf4j/commit/f3e768260b6f109d1f207e43c48e8c…] The approach should not affect the performance, but increases readability and extensibility. The message builder can be extended for other stuff as well, but this is enough for us at least. To avoid breaking all existing implementations I changed the module name to "slf4j-api-jdk8" and implemented so far unused methods like "info()" as "default" interface methods. The idea is to provide that extra package as an alternative for all Java 8 applications that want to replace their "slf4j-api" dependency. Like other libraries provide backwards-compatible versions for old JDKs. Its fully compatible with the whole SLF4J ecosystem. The module will be developed in the branch "slf4j-api-jdk8" forever. Thus during a release all modules will be released, master merged and only this module released from the branch as well. I would really like to see this extension within SLF4J instead of continuing with an own "extension library" used only internally. So far I've implemented just the info() method to show the idea, but if its accepted to be part of officiel SLF4J I will continue with the implementation. Cheers, Christian -- 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) 06 Dec '17

06 Dec '17

[ https://jira.qos.ch/browse/SLF4J-422?page=com.atlassian.jira.plugin.system.… ] Eric Pabst commented on SLF4J-422: ---------------------------------- Here is a proposed fix: https://github.com/qos-ch/slf4j/pull/191 > 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