April 2022 - slf4j-dev - mailman3.qos.ch

[JIRA] Updates for SLF4J-548: Loading services (plugins) with the caller's ClassLoader
by QOS.CH (JIRA) 30 Apr '22

30 Apr '22

SLF4J / SLF4J-548 [Open] Loading services (plugins) with the caller's ClassLoader ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-548 ============================== 1 comment ------------------------------ Ceki Gülcü on 30/Apr/22 11:24 PM After studying the topic of class loaders quite extensively in the past, I can say with some confidence that class loaders and loggers make for a surprisingly complex combination. Around 2002, applications using Jakarta Commons Logging (JCL) would suffer from complex bugs due to the [dynamic class loader techniques|https://articles.qos.ch/thinkAgain.html] employed by JCL. The situation was so bad that I was convinced at the time that the `log4j` project would not survive wide spread usage of JCL. SLF4J was created as a more robust alternative to JCL. Anyway, it would be technically possible to add a method allowing the user to specify the class loader that {{LoggerFactory}} should use in its {{findServiceProviders()}} method. However, I don't think it would be easy to employ this method without significant leg work. In particular, the class loader option has to be set before the first invocation of LoggerFactory.getLogger(). If you can guarantee that, you can also guarantee setting TCCL by calling {{Thread.setContextClassLoader}}. This is the solution I would propose to you in the meantime until a more generic solution is incorporated into SLF4J. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-548: Loading services (plugins) with the caller's ClassLoader
by QOS.CH (JIRA) 30 Apr '22

30 Apr '22

SLF4J / SLF4J-548 [Open] Loading services (plugins) with the caller's ClassLoader ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-548 ============================== 1 comment ------------------------------ Ralph Goers on 30/Apr/22 10:32 PM Actually, only looking in one ClassLoader is probably insufficient. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-548: Loading services (plugins) with the caller's ClassLoader
by QOS.CH (JIRA) 30 Apr '22

30 Apr '22

SLF4J / SLF4J-548 [Open] Loading services (plugins) with the caller's ClassLoader ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-548 ============================== Issue created ------------------------------ pierre created this issue on 30/Apr/22 5:32 PM Summary: Loading services (plugins) with the caller's ClassLoader Issue Type: Improvement Affects Versions: 1.8.0-beta4 Assignee: SLF4J developers list Components: Core API Created: 30/Apr/22 5:32 PM Priority: Major Reporter: pierre Description: Hi, First of all congratulations and thank you for this excellent API. I want to use your Slf4j API in my JDBC driver for the Uno LibreOffice / OpenOffice API. I want to use it to redirect loggers from HsqlDB and H2 to the Uno Logger API, but I can't use it without modifying the slf4j-api.jar service loader. Let me explain my problem. Services provider or plugins seem to be loaded in the file: [LoggerFactory.java|https://github.com/qos-ch/slf4j/blob/master/slf4j-api/sr…] with the commande: {code:java} ServiceLoader<SLF4JServiceProvider> serviceLoader = ServiceLoader.load(SLF4JServiceProvider.class); {code} but without ClassLoader who is by default the current Thread's ClassLoader. My application, a jar file that embeds the slf4j-Api and a service provider for the Uno Logger archives (slf4j-api.jar and UnoLogger.jar), that wants to use Slf4j is loaded by a URLClassLoader by LibreOffice which extend the CLASSPATH and which has as ClassLoader the current Thread's ClassLoader. As a result, Services or Plugins can't never see the extended CLASSPATH from my application and never load... Would it be possible to load the services with the ClassLoader of the caller: {code:java} ServiceLoader<SLF4JServiceProvider> serviceLoader = ServiceLoader.load(SLF4JServiceProvider.class, LoggerFactory.class.getClassLoader()); {code} instead of that of the current Thread. This will allow CLASSPATH inheritance through ClassLoaders... and this is the normal behaviour of {code:java} new Object() {code} or {code:java} Class.forName() {code} Thank you. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

Integrating jul-to-slf4j into OSS-Fuzz
by Dae Glendowne 29 Apr '22

29 Apr '22

Hi all, I have prepared the initial integration (https://github.com/CodeIntelligenceTesting/oss-fuzz/commit/caac4be25588f4b4…) of jul-to-slf4j into google oss-fuzz. This will enable continuous fuzzing of this project, which will be conducted by Google. Bugs that will be found by fuzzing will be reported to you. After the initial integration of this project into oss-fuzz, I will continue to add additional fuzz tests to improve the code coverage over time. The integration requires a primary contact, someone to deal with the bug reports submitted by oss-fuzz. The email address needs to belong to an established project committer and be associated with a Google account as per here (https://google.github.io/oss-fuzz/getting-started/accepting-new-projects/) When a bug is found, you will receive an email that will provide you with access to ClusterFuzz, crash reports, and fuzzer statistics. More than 1 person can be included. Please let me know who I should include, if anyone. Jazzer (https://github.com/CodeIntelligenceTesting/jazzer) is used for fuzzing Java applications. Jazzer is a coverage-guided, in-process fuzzer for the JVM platform developed by Code Intelligence. It is based on libFuzzer and brings many of its instrumentation-powered mutation features to the JVM. Jazzer has already found several bugs in JVM applications: Jazzer Findings (https://github.com/CodeIntelligenceTesting/jazzer#findings) Please let me know if you have any questions regarding fuzzing or the oss-fuzz integration. Dae Glendowne Application Security Engineer | Customer Success Code Intelligence GmbH Rheinwerkallee 6 D-53227 Bonn, Germany https://www.code-intelligence.com Managing Directors: Sergej Dechand, Dr. Henning Perl Registered office and court of registry: Bonn, Germany, HRB 23408 Hinweis: Im Rahmen dieser Korrespondenz werden von Code Intelligence Ihre personenbezogenen Daten verarbeitet. Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

2 1

Integrating slf4j-api into OSS-Fuzz
by Dae Glendowne 29 Apr '22

29 Apr '22

Hi all, I have prepared the initial integration (https://github.com/CodeIntelligenceTesting/oss-fuzz/commit/882cfd41586879ce…) of slf4j-api into google oss-fuzz. This will enable continuous fuzzing of this project, which will be conducted by Google. Bugs that will be found by fuzzing will be reported to you. After the initial integration of this project into oss-fuzz, I will continue to add additional fuzz tests to improve the code coverage over time. The integration requires a primary contact, someone to deal with the bug reports submitted by oss-fuzz. The email address needs to belong to an established project committer and be associated with a Google account as per here (https://google.github.io/oss-fuzz/getting-started/accepting-new-projects/) When a bug is found, you will receive an email that will provide you with access to ClusterFuzz, crash reports, and fuzzer statistics. More than 1 person can be included. Please let me know who I should include, if anyone. Jazzer (https://github.com/CodeIntelligenceTesting/jazzer) is used for fuzzing Java applications. Jazzer is a coverage-guided, in-process fuzzer for the JVM platform developed by Code Intelligence. It is based on libFuzzer and brings many of its instrumentation-powered mutation features to the JVM. Jazzer has already found several bugs in JVM applications: Jazzer Findings (https://github.com/CodeIntelligenceTesting/jazzer#findings) Please let me know if you have any questions regarding fuzzing or the oss-fuzz integration. Dae Glendowne Application Security Engineer | Customer Success Code Intelligence GmbH Rheinwerkallee 6 D-53227 Bonn, Germany https://www.code-intelligence.com Managing Directors: Sergej Dechand, Dr. Henning Perl Registered office and court of registry: Bonn, Germany, HRB 23408 Hinweis: Im Rahmen dieser Korrespondenz werden von Code Intelligence Ihre personenbezogenen Daten verarbeitet. Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

1 0

[JIRA] Updates for SLF4J-531: MDC should support stack values identified by key
by QOS.CH (JIRA) 17 Apr '22

17 Apr '22

SLF4J / SLF4J-531 [Open] MDC should support stack values identified by key ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-531 ============================== 1 comment ------------------------------ Piotr P. Karwasz on 17/Apr/22 9:30 PM [~ceki], I think we all agree on the answer to Q1: since you can map {{List<String>}} into a {{Map<String, Deque>}} without loss of information, the latter is better. My request was to introduce the requirement for {{MDC}} to behave as a *single* {{Map<String, Deque>}}, as in Ralph's examples. One of the strong points of SLF4J is IMHO that it allows you to access the *current* features of several logging frameworks in an uniform way. SLF4J 2.0 bindings could: * use the native NDC of Reload4j and Log4j2 if the key is empty and encode the {{Deque}} as JSON array (or similar) for the other keys, * since JBoss has a thread bound {{Map<String, Object>}}, the JBoss binding would be almost trivial. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-531: MDC should support stack values identified by key
by QOS.CH (JIRA) 16 Apr '22

16 Apr '22

SLF4J / SLF4J-531 [Open] MDC should support stack values identified by key ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-531 ============================== 1 comment ------------------------------ Ralph Goers on 16/Apr/22 6:53 PM Prior to any of this Log4j supported a ThreadContext that contained a Map<String, String> per thread and a ContextStack<String> per thread. These were both included since Log4j 1.x had equivalents for both. While the Map has proven highly useful the Stack has never seemed useful to me since the requirement that the values be removed in the opposite order they were added always seemed fragile. While the implementation of the ThreadContextStack is done with a List in Log4j 2, users still have to access it as a Stack in the API, so treating it as a List would be a mistake. The Thread Context Stack is a queue that is accessed via push(), pop(), and peek() as defined by ThreadContext.ContextStack. The ThreadContextStack in Log4j 2 has always been a separate data structure as it was in Log4j 1 - i.e. a single stack per thread. As for which questions we would be discussing I don't think we are discussing Q1 at all. The single ThreadContextStack has existed for years. It isn't a matter of which is better. It is a simple matter of it has to continue to exist to ensure compatibility. As for Q2, Again, I think the question is mis-framed. We are not comparing a Map<String, String> to a ThreadContextStack nor are we discussing merging the ThreadContextStack with the Map. IIUC your use case is in support of span ids. I've never found the value of them myself (we use a request id, which should be analogous to a trace id) and session ids (that have nothing to do with an actual server session but represent a single user's login), but given this I can understand why you would want a data structure that is separate from the standard single NDC as users might be using that for unexpected stuff. That said, using the ThreadContextMap works for that so long as you are sure the key doesn't conflict with some other usage (of course, a key conflict could also arise with your use of a Map<String, Dequeue<String>> as well). I would suggest that the appropriate way to deal with this would be to use push and pop as you have shown them. If you want the Map to contain a list instead then you should do ThreadContextMap.add(key, "value"); and ThreadContextMap.getFirst(key) or getLast(key) or removeFirst(key) or removeLast(key) or remove(index). In other words, there is value in having the MDC support various types of collections or a single value, not just Dequeues. If you want to deal with it as a Collection then use the appropriate methods. If you want to deal with it as a List then use the methods appropriate for that. So long as you mandate that there is no guarantee that the keys will be unique across data representations then you are free to implement this using a single Map or using multiple Maps. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-531: MDC should support stack values identified by key
by QOS.CH (JIRA) 16 Apr '22

16 Apr '22

SLF4J / SLF4J-531 [Open] MDC should support stack values identified by key ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-531 ============================== 1 comment ------------------------------ Ceki Gülcü on 16/Apr/22 11:07 AM When discussing this with [~pkarwasz], I assumed that we were talking about a map of type {{Map<String, Dequeue<String>>}} where thread-local stacks were accessed by a key. Let S1 designate this type, i.e. {{Map<String, Dequeue<String>>}}. It looks like log4j2's implementation proposes a single stack accessed without a key, that is with a structure of type {{List<String>}}. Let S2 designate the type {{List<String>}}. So, there is the question of which data structure is better, i.e. S1 or S2. Let Q1 designate this question. Let M1 designate type {{Map<String, String>}} stored in a thread local. There seems to be wide agreement on the usefulness of this data structure commonly called as MDC. There is also the second question, call it Q2, of whether the same key can or cannot be used to access data in both data structures M1 and S1. If M1 and S1 are separate structures, it makes sense to allow the same key to be used to access different and separate data in these to structures. If however, M1 and S1 are merged into a single super data structure, then the same key can access only a single data point. Are we discussing Q1 or Q2 or both? Anyway, assuming nested data is useful, it seems pretty natural to further assume that there will be multiple nested data values. These must be accessed separately by key. A no key solution implicitly assumes that nested data is *not* useful. Indeed, this was my position for a long time. However, if you need to manage spandIds then S1 is the obvious data structure. Moreover, given that spandIds can be critical in some applications, it is safer to assume that there may be several parallel spandId uses which will need to be referenced by different keys. I'll stop here before this comment gets too unwieldy. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-531: MDC should support stack values identified by key
by QOS.CH (JIRA) 16 Apr '22

16 Apr '22

SLF4J / SLF4J-531 [Open] MDC should support stack values identified by key ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-531 ============================== 1 comment ------------------------------ Ralph Goers on 16/Apr/22 9:45 AM To be honest, I can count on one hand with less than all 5 fingers the number of people who I can recall that have inquired about the NDC in either Log4j's Jira or mailing lists. So the idea that somehow multiple stacks would be useful is surprising since the vast majority of users don't use the ThreadContextStack/NDC at all. However, it does make sense that the ThreadContextMap (MDC) should support collections of values as well as single values. Although this implementation uses a Deque instead of a List it does fulfill that purpose. So when looking at it from that perspective it makes sense that keys in the Map should not overlap since it is an extension of the MDC. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-531: MDC should support stack values identified by key
by QOS.CH (JIRA) 15 Apr '22

15 Apr '22

SLF4J / SLF4J-531 [Open] MDC should support stack values identified by key ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-531 ============================== 1 comment ------------------------------ Ceki Gülcü on 16/Apr/22 12:12 AM [~pkarwasz] From what I could gather, log4j 2.x supports a single stack stored in a {{ThreadLocal}} accessed _without _a key. JBoss logging has *no* support for a stack stored in a {{ThreadLocal}}. Thus, SLF4J's stack stored by key in a {{ThreadLocal}} is different than the stack with no key as offered in log4j 2.x. If there are multiple use cases for a stack in the same application, then it seems to me that the only way to avoid collisions in the stored values is to access them with different keys. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0