[slf4j-dev] [JIRA] Updates for SLF4J-548: Loading services (plugins) with the caller's ClassLoader

[QOS.CH (JIRA)]

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)