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

[JIRA] (SLF4J-124) Add ability to log at a dynamic level
by QOS.CH (JIRA) 06 Jan '18

06 Jan '18

[ https://jira.qos.ch/browse/SLF4J-124?page=com.atlassian.jira.plugin.system.… ] Joel Handwell commented on SLF4J-124: ------------------------------------- Came from Stackoverflow and created JIRA account just for voting this. Hope this issue to be reviewed. > Add ability to log at a dynamic level > ------------------------------------- > > Key: SLF4J-124 > URL: https://jira.qos.ch/browse/SLF4J-124 > Project: SLF4J > Issue Type: Sub-task > Components: Core API > Affects Versions: 1.5.x > Environment: Operating System: All > Platform: All > URL: http://stackoverflow.com/questions/2621701/setting-log-level-of-message-at-… > Reporter: Robert Elliot > Assignee: SLF4J developers list > Attachments: Util.java.patch > > > It is occasionally useful to have a log method that takes a level as a parameter. The necessary methods can be added to the Util class without any compatibility issues as far as I can see - see attached patch. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

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