December 2019 - slf4j-dev - mailman3.qos.ch

Proposal for SLF4J 2.0 Logger API
by Remko Popma 11 Jan '20

11 Jan '20

Hi Ceki, Sorry for raising this via the wrong channel initially. If there is still time for SLF4J 2.0, I propose changing the Logger methods that take a String to accept an Object instead (excl. the methods that take format params); this enables various use cases and optimizations in SLF4J implementations that are not possible with the String-based API. One potential use case is a garbage-free implementations of the API. A Logger implementation could check if the specified Object implements java.lang.CharSequence, for example, and extract the message text without allocating a temp String object. GC-sensitive apps could then log StringBuilder objects, for example. Another use case is binary logging; if the logging implementation has an efficient way to map domain objects to a binary representation (as opposed to a textual representation), then this could be both faster and produce more compact output, which may be of interest to a certain type of applications. The binary presentation could be converted back to text offline or on-demand. Such use cases are not possible if the SLF4J API only provides methods that accept Strings: information has been lost by the time the logging implementation is invoked. I cannot think of any downside, only upside, of replacing methods like Logger.info(String) with Logger.info(Object) in the API. For API users this would be a backwards compatible change. API implementations would need to do something extra to get the textual representation from the specified Object, but not much - this could be as simple as calling toString on it. However, an Object-based API opens the door for various use cases and optimizations in SLF4J implementations that are otherwise not possible, as suggested above. I'm hoping that the 2.0 major release would be an opportunity for such changes... Thoughts? Remko.

5 14

[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

[JIRA] (SLF4J-469) Potential memory leaks if there is no underlying implementation
by QOS.CH (JIRA) 16 Dec '19

16 Dec '19

[ https://jira.qos.ch/browse/SLF4J-469?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü resolved SLF4J-469. ------------------------------ Resolution: Fixed Fixed in [commit 306d8fd2|https://github.com/qos-ch/slf4j/commit/306d8fd23d89b0a] on master and in [commit c6c7a98a7ee1|https://github.com/qos-ch/slf4j/commit/c6c7a98a7ee1e7138] on the 1.7 maintenance branch. > Potential memory leaks if there is no underlying implementation > --------------------------------------------------------------- > > Key: SLF4J-469 > URL: https://jira.qos.ch/browse/SLF4J-469 > Project: SLF4J > Issue Type: Bug > Affects Versions: 1.7.26 > Environment: java 8 > slf4j 1.7.26 > > Reporter: yu > Assignee: Ceki Gülcü > Priority: Critical > Labels: logging, substitution > Fix For: 2.0.0-alpha2, 1.7.30 > > > > *If I don't have 'logback' 'log4j'...... Implementation class* > The problem lies in the method > *public static ILoggerFactory getILoggerFactory()* > first Thread1: > {code:java} > if (INITIALIZATION_STATE == UNINITIALIZED) { > init..... > } > {code} > secode Thread2: > {code:java} > case ONGOING_INITIALIZATION: > return SUBST_FACTORY;{code} > obtained "SUBST_FACTORY"， > and obtained "SubstituteLogger" > > third: > Thread1: > {code:java} > //init failed cache "NoClassDefFoundError" > INITIALIZATION_STATE = NOP_FALLBACK_INITIALIZATION; > {code} > *The SubstituteLogger obtained by Thread2 will always output the log to the queue until the memory overflows.* > {code:java} > // code placeholder > synchronized public Logger getLogger(String name) { > SubstituteLogger logger = loggers.get(name); > if (logger == null) { > logger = new SubstituteLogger(name, eventQueue, postInitialization); > loggers.put(name, logger); > } > return logger; > } > public void info(String msg) { > delegate().info(msg); > } > Logger delegate() { > if(_delegate != null) { //_delegate== null forever > return _delegate; > } > if(createdPostInitialization) { createdPostInitialization == false forever > return NOPLogger.NOP_LOGGER; > } else { > return getEventRecordingLogger(); > } > } > {code} > > > > -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0