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 ------------------------------ Chad Wilson on 03/Sep/22 10:06 AM Yeah, it's probably not 100% the same as yours (I am still figuring out a full fix/workaround in my case in cases where I have both Logback 1.2 and Logback 1.4 loaded in different classloaders in the same VM, but I concluded it also relates to possible downstream problems caused by the ServiceLoader change in situations where logback is being loaded in different classloader configurations, and since there was some discussion above referring back to all the old challenges with JCL and parent-first and child-first class loaders, it seemed relevant. It's maybe worth noting that the way the ServiceLoader is used in logback *1.2.x* for finding its Configurator is a bit inconsistent with the new SLF4J 1.8+ approach (for whatever reason), instead using the classloader of the caller rather than solely relying on the TCCL: *ContextInitializer.autoConfig()* https://github.com/qos-ch/logback/blob/ca0cf172f680308938515b8a5d69348759ee947c/logback-classic/src/main/java/ch/qos/logback/classic/util/ContextInitializer.java#L130-L151 *EnvUtil.loadFromServiceLoader(clazz)* https://github.com/qos-ch/logback/blob/ca0cf172f680308938515b8a5d69348759ee947c/logback-classic/src/main/java/ch/qos/logback/classic/util/EnvUtil.java#L47-L53 ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59) _______________________________________________ slf4j-dev mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/slf4j-dev
