[logback-dev] Better introspection into logging setup

[Durchholz, Joachim]

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

Agreed, the official interface associates no explicit level semantics.
(In fact a logger that retrieves just a random 1% sample of all log
messages might do exactly that.)

Not that it changes anything about the point I'm making - since SLF4J
does not make assumptions about inter-level dependencies, bindings and
bridges are free to do whatever pleases them, including establishing a
level relationship.

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

Routines that call LoggerFactory and Logger see
* that there's a namespace that maps names to Loggers
(ILoggerFactory#getLogger), and
* that each Logger has a level (in the form of isXEnabled).
Nothing of that is specific to Logback.

(In fact it cannot be specific to Logback. It's the interface that SLF4J
exposes to client code that may emit messages, and the whole point of
SLF4J is abstracting away the specifics of logback or any other
backend.)

> 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:
> 
> 	So for each logger that's configured for Logback, I 
> 	want to create a JUL logger with the same logging level
> 	as its Logback counterpart. This should drastically cut
> 	down on the number of log messages created and thrown
> 	away.

SLF4J can use other backends than logback, and the JUL bridge should
work in these cases, too.
So I have to strongly disagree: using logback specifics for the JUL
bridge would defeat the whole purpose of SLF4J.

One thing where I was overly specific was when I was referring to
logback.xml.
With a different backend, the configuration file would have a different
name.

So, it's really the configuration as far as it's exposed at the SLF4J
level that needs to be reflected down to JUL.

Regards,
Jo