[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
------------------------------

pierre on 01/May/22 10:32 PM
Hi Ceky,

I have read the article [Taxonomy of class loader issues encountered when using Jakarta Commons Logging|https://articles.qos.ch/classloader.html], it seems the problem with JCL's ClassLoader stems from the fact that it uses a Child-first ClassLoader delegation model.

I don't want to use a Child-first ClassLoader, I'd like to use the standard Java SDK Parent-first delegation model, but without breaking the extension of the CLASSPATH through ClassLoader inheritance.
I don't know enough about Java and ClassLoader, but it seems to me that using the caller's ClassLoader or changing the current.Thread ClassLoader is the same thing.

In any case currently it is not possible to load an application using Slf4j and a Service Provider other than using the JRE  bootstrap's ClassLoader. (ie: java -cp myapp.jar)





==============================
 This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)