- slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-481) log4j-to-slf4j Null Throwable
by QOS.CH (JIRA) 02 Jan '20

02 Jan '20

Anton created SLF4J-481: --------------------------- Summary: log4j-to-slf4j Null Throwable Key: SLF4J-481 URL: https://jira.qos.ch/browse/SLF4J-481 Project: SLF4J Issue Type: Bug Environment: log4j-to-slf4j-2.11.1 Reporter: Anton Assignee: SLF4J developers list Priority: Minor In org.apache.logging.slf4j.SLF4JLogger.logMessage(...) Throwable t is passed to underlying SLF4J Logger implementation even if it is null, which causes the following method signature to apply, which is wrong: {code:java} Logger.trace(Marker marker, String format, Object arg1, Object arg2){code} There should be a check in this method, if Throwable t argument is null, then call: {code:java} Logger.trace(Marker marker, String format, Object arg){code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-479) JUL-SLF4J Bridge - sourceMethod not logged
by QOS.CH (JIRA) 02 Jan '20

02 Jan '20

[ https://jira.qos.ch/browse/SLF4J-479?page=com.atlassian.jira.plugin.system.… ] Anton commented on SLF4J-479: ----------------------------- Kind reminder. > JUL-SLF4J Bridge - sourceMethod not logged > ------------------------------------------ > > Key: SLF4J-479 > URL: https://jira.qos.ch/browse/SLF4J-479 > Project: SLF4J > Issue Type: Bug > Environment: JUL SLF4J Bridge 1.7.x > Reporter: Anton > Assignee: SLF4J developers list > > Consider an example from MSSQL JDBC Driver: > [https://github.com/microsoft/mssql-jdbc/blob/77f9f1086049e5ea4ff11fb5434fdd…] > {code:java} > loggerExternal.entering(getClassNameLogging(), "commit");{code} > > _Actual result_: The *sourceMethodName* ("commit") is not passed to the underlying SLF4J implementation, via JUL-SLF4J Bridge. > I.e. the sourceMethod is not logged in this case. > > _Expected result:_ JUL-SLF4J Bridge should pass sourceMethodName to SLF4J implementation. > Please also check if there are any other such attributes affected. > Suggested to fix in org.slf4j.bridge.SLF4JBridgeHandler. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-480) When using `parallelStream()` function to do something, MDC does not work.
by QOS.CH (JIRA) 30 Dec '19

30 Dec '19

Liu Cong created SLF4J-480: ------------------------------ Summary: When using `parallelStream()` function to do something, MDC does not work. Key: SLF4J-480 URL: https://jira.qos.ch/browse/SLF4J-480 Project: SLF4J Issue Type: Bug Reporter: Liu Cong Assignee: SLF4J developers list Priority: Critical I need to log a few attributes of the request like the request id and the locale, but when using parallelStream, it seems that the ThreadLocal of the MDC looses the information. Ive analyzed the solution of passing the MDC context between the threads when creating the parallelStream but it seems dirty and I also have a lot of usages of the parallelStream. Is there any other way of doing this? Thank you -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-479) JUL-SLF4J Bridge - sourceMethod not logged
by QOS.CH (JIRA) 24 Dec '19

24 Dec '19

Anton created SLF4J-479: --------------------------- Summary: JUL-SLF4J Bridge - sourceMethod not logged Key: SLF4J-479 URL: https://jira.qos.ch/browse/SLF4J-479 Project: SLF4J Issue Type: Bug Environment: JUL SLF4J Bridge 1.7.x Reporter: Anton Assignee: SLF4J developers list Consider an example from MSSQL JDBC Driver: [https://github.com/microsoft/mssql-jdbc/blob/77f9f1086049e5ea4ff11fb5434fdd…] {code:java} loggerExternal.entering(getClassNameLogging(), "commit");{code} _Actual result_: The *sourceMethodName* ("commit") is not passed to the underlying SLF4J implementation, via JUL-SLF4J Bridge. I.e. the sourceMethod is not logged in this case. _Expected result:_ JUL-SLF4J Bridge should pass sourceMethodName to SLF4J implementation. Please also check if there are any other such attributes affected. Suggested to fix in org.slf4j.bridge.SLF4JBridgeHandler. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-168) Feature-Request: allow Object as value in MDC.put
by QOS.CH (JIRA) 24 Dec '19

24 Dec '19

[ https://jira.qos.ch/browse/SLF4J-168?page=com.atlassian.jira.plugin.system.… ] Jon Wolski commented on SLF4J-168: ---------------------------------- To build on what @nithril said: I have a use case where I'm logging everything JSON-serialized and ingesting that into an ELK stack (technically "EFK", Filebeat instead of Logstash). I want to log certain attributes as (JSON) Number so that I can do numeric operations on that data in Kibana dashboards. Ironically, the data still needs to be converted to String (because I'm writing JSON, i.e. character data, not something like Avro or Protobuf), but not a _JSON_ String. i.e. I need my 4 byte integer serialized as a string of decimal characters, but I do not need the double quotes surrounding it. In this case, not only do I wish to `MDC.put` non-String, I'd really like to `put` a primitive. I'll settle for a boxed primitive, though, if I must. > Feature-Request: allow Object as value in MDC.put > ------------------------------------------------- > > Key: SLF4J-168 > URL: https://jira.qos.ch/browse/SLF4J-168 > Project: SLF4J > Issue Type: Bug > Components: Core API > Affects Versions: 1.5.x > Environment: Operating System: Windows XP > Platform: PC > Reporter: Michael Wenig > Assignee: SLF4J developers list > > Currently Log4j accepts in MDC.put java.lang.Object as value while slf4j only accepts strings. > If you have some Information which is only needed rarely and expensive to construct you are either forced to do a toString() for each request or you have to fall back to the native use of log4j. > For example we have an Object which wraps a httpServletRequest and will be inserted in the MDC via a ServletFilter in order to be used in ERROR-Level (configured via layout of the according appender). This objects constructs a complete request dump via toString() which is expensive as for example the values of some parameters gets masked (e.g. passwords) for privacy. > Using log4j this object was put in the MDC as object and toString() was only called if the information was really needed in a log statement (which is only the case when an unexpected error occurs and will normally not occur). > When we switched to slf4j we realized that we have to either call toString() explicitely in the filter (which would result in an expensive calculation on each request) or have to fall back to log4j for this case which reduces compatibility. > I would suggest to explicitly allow MDC.put(String, Object) and delegate it directly to the underlying implementation if it is supported. If it is not supported the adapter could call the toString() method accepting the overhead. (This should be documented of course!) > Are there any reasons not to support this? It is a major issue for us as we are currently not able to switch the logging mechanism (and the functionality is part of a library) -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[qos-ch/slf4j] 623094: next version is 1.7.31
by Ceki Gulcu 20 Dec '19

20 Dec '19

Branch: refs/heads/1.7-maintenance Home: https://github.com/qos-ch/slf4j Commit: 62309486d3229ef9a702415e3be1c6f6916b6fe2 https://github.com/qos-ch/slf4j/commit/62309486d3229ef9a702415e3be1c6f6916b… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2019-12-20 (Fri, 20 Dec 2019) Changed paths: M integration/pom.xml M jcl-over-slf4j/pom.xml M jul-to-slf4j/pom.xml M log4j-over-slf4j/pom.xml M osgi-over-slf4j/pom.xml M pom.xml M slf4j-android/pom.xml M slf4j-api/pom.xml M slf4j-ext/pom.xml M slf4j-jcl/pom.xml M slf4j-jdk14/pom.xml M slf4j-log4j12/pom.xml M slf4j-migrator/pom.xml M slf4j-nop/pom.xml M slf4j-simple/pom.xml M slf4j-site/pom.xml Log Message: ----------- next version is 1.7.31

1 0

[qos-ch/slf4j] 715b59: news about 1.7.30
by Ceki Gulcu 20 Dec '19

20 Dec '19

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 715b5911858b13a89e5fa9df13f4ca03d72850f7 https://github.com/qos-ch/slf4j/commit/715b5911858b13a89e5fa9df13f4ca03d728… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2019-12-20 (Fri, 20 Dec 2019) Changed paths: M pom.xml M slf4j-site/src/site/pages/news.html Log Message: ----------- news about 1.7.30

1 0

[JIRA] (SLF4J-478) Updating from 1.7.25 to 2.0.0-alpha1 breaks
by QOS.CH (JIRA) 18 Dec '19

18 Dec '19

Lingchao Chen created SLF4J-478: ----------------------------------- Summary: Updating from 1.7.25 to 2.0.0-alpha1 breaks Key: SLF4J-478 URL: https://jira.qos.ch/browse/SLF4J-478 Project: SLF4J Issue Type: Bug Reporter: Lingchao Chen Assignee: SLF4J developers list When I try to upgrade sl4j-api from 1.7.25 to version 1.8.X and 2.X. The following code breaks. {code:java} public class TestSl4j extends AbstractTest4StdOut { @Test public void demo() throws Exception{ final Logger logger = LoggerFactory.getLogger(TestSl4j.class); // Log in Main Thread logger.info("Log in main!"); assertEquals("[] {} - Log in main!", getLogAndClear()); } } public abstract class AbstractTest4StdOut { @Rule public final SystemOutRule systemOutRule = new SystemOutRule().enableLog(); protected static final long START_TIME_STAMP = System.currentTimeMillis(); protected String getLogAndClear() { System.out.flush(); final String out = systemOutRule.getLog(); systemOutRule.clearLog(); final int idx = out.indexOf('\n'); return out.substring(idx + 1, out.length() - 1); // trim first line and last '\n' } } {code} The code should pass, but it throws an error: {code:java} [ERROR] demo(TestSl4j) Time elapsed: 0.018 s <<< ERROR! java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at demo(TestSl4j.java:19) {code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

Release of SLF4J version 1.7.30
by Ceki 16 Dec '19

16 Dec '19

Hello all, I am happy to announce the immediate availability of SLF4J version 1.7.30, a maintenance release fixing bugs with no new features. Please refer to the the news page for more details on this release: http://www.slf4j.org/news.html The relevant artifacts should hit the Maven central repository within the next few hours. The 1.7.x series: The Simple Logging Facade for Java or (SLF4J) serves as a simple facade or abstraction for various logging frameworks, e.g. java.util.logging, log4j and logback, allowing the end user to plug in the desired logging framework at deployment time. The 1.7.x series adds varargs support in Logger methods. Compared to previous versions, 1.7.5 significantly improves logger retrieval times. Users are highly encouraged to migrate to SLF4J 1.7.5 or later. Binary compatibility: Mixing mixing different versions of slf4j-api.jar and SLF4J binding can cause problems. For example, if you are using slf4j-api-1.7.1.jar, then you should also use slf4j-simple-1.7.1.jar, using slf4j-simple-1.5.5.jar will not work. From the client's perspective all versions of slf4j-api are compatible. Client code compiled with slf4j-api-N.jar will run perfectly fine with slf4j-api-M.jar for any N and M. You only need to ensure that the version of your binding matches that of the slf4j-api.jar. You do not have to worry about the version of slf4j-api.jar used to compile a given dependency in your project. You can always use *any* version of slf4j-api.jar, and as long as the version of slf4j-api.jar and its binding match, you should be fine. Downloading SLF4J: You can download SLF4J, including full source code, class files and documentation on our download page: http://www.slf4j.org/download.html Announcement mailing list: You can receive SLF4J related announcements by subscribing to the SLF4J announce mailing list. To subscribe to QOS.ch announce list, please visit the following URL. http://www.qos.ch/mailman/listinfo/announce You may also receive announcements via twitter: https://twitter.com/qos_ch Enjoy, -- Ceki Gülcü

1 0

[qos-ch/slf4j]
by Ceki Gulcu 16 Dec '19

16 Dec '19

Branch: refs/tags/v_1.7.30 Home: https://github.com/qos-ch/slf4j

1 0