<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>With "SLF4J configuration", I mean whatever configuration the logging<br>backend uses.<br>It is even "the SLF4J configuration" in a broader sense: you can query<br>SLF4J about its properties. It's just a subset of these properties,<br>namely the logging level of each individual logger, and you need to know<br>the logger's name in advance, but it's a queryable configuration all<br>right.<br><br></div></blockquote><div><br></div>No it's not; the SLF4J Logger interface has no inherent concept of a level. It has "isXEnabled" methods, but there's nothing to stop you writing an implementation that returns true (or false) for all of those. You could even write an implementation that returns a logger with those methods randomly returning true or false each time you called it if you wanted to - SLF4J doesn't care. The fact that there happen to be different loggers for different names with different persistent configured levels in Logback is an implementation detail specific to Logback.</div><div><br></div><div>It's going to be a lot, lot easier if we refer to Logback loggers configured for Logback, so if you don't mind I'll quote you as if you had:</div><div><br><blockquote type="cite"><div>So for each logger that's configured for Logback, I want to create a JUL<br>logger with the same logging level as its Logback counterpart. This should</div></blockquote><blockquote type="cite"><div>drastically cut down on the number of log messages created and thrown<br>away.<br></div></blockquote></div><br><div>To get hold of the root logback logger you can use the following:</div><div><br></div><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; "><span style="color: rgb(145, 28, 103); ">import</span> org.slf4j.LoggerFactory;</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; "><span style="color: rgb(145, 28, 103); ">import</span> ch.qos.logback.classic.Logger;</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; "><span style="color: rgb(145, 28, 103); ">import</span> ch.qos.logback.classic.LoggerContext;</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; ">...</div></div><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; ">LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; "><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; ">Logger rootLogger = lc.getLogger(Logger.<span style="color: rgb(25, 46, 201); ">ROOT_LOGGER_NAME</span>);</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; ">However, oddly you can't then ask the root logger what children it has - it's stored as a private variable (List<Logger> childrenList) with no public accessor. I don't know what the reason for this is (I'm also curious why it's a List - it looks like a Set to me, order irrelevant but no duplicates). I see no reason why it shouldn't have a public accessor exposing an unchangeable view of this collection to allow the introspection you ask for - you could then recursively walk the Logger tree. It would be trivial to branch logback in git and implement this.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; ">Another approach might be to look at the Joran configurator for logback and add a listener to it as each Logback logger is configured that creates the corresponding JULI logger (if that's the right JULI terminology).</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; ">Obviously both of these solutions would be Logback specific, but that's unavoidable - there is no sensible way to add Logger introspection to SLF4J, it just doesn't fit the interface nature of SLF4J.</div></div></div></body></html>