[logback-dev] Better introspection into logging setup

[Durchholz, Joachim]

I'd like to pursue this issue further.

Actually the title is a bit of a misnomer. What I really want to achieve
is that the j.u.l. machinery takes its configuration from the standard
SLF4J-configured loggers.

I'd like to discuss whether that's a useful thing within the scope of
the SLF4J project.


Reason against:

A) There is a simple workaround:
Configure any j.u.l.-using library with the standard j.u.l. facilities.
Make SLF4J use Level.ALL on the namespace(s) that the library lives in.
(Note that any workaround needs to make sure that (a) any log messages
generated actually hit their relevant appenders, and that (b) no
unneeded log messages are generated. I think the above workaround
satisfies that - is that correct?)

B) This is a somewhat intrusive change. SLF4J needs a new
ILoggerFactory#getAllLoggers() returning a Collection<Logger>, and it
needs to send an event for any configuration change as it becomes aware
of them (such as new loggers encountered during logback.xml evaluation,
or hardcoded creation or modification of loggers from inside the
program).
getAllLoggers() would be relatively easy, adding the required event
machinery could affect many places in SLF4J.
Maybe it would be easier to follow the configuration from logback.xml
instead of following run-time changes (but see below).


Reasons for:

1) All bridge jars (jcl-over-slf4j etc.) obey the SLF4J logging
configuration. jul-to-slf4j.jar does not. This can confuse newbies and
makes the learning curve steeper; SLF4J's main selling point is that
it's a (mostly) drop-in replacement.
To fully reap this benefit, it would be necessary to follow runtime
changes in the SLF4J configuration changes. This would be mostly
installation of new loggers, though e.g. logback loggers could change
their configuration even though the SLF4J API does not (nor would the
SLF4J API need such functions, it just needs to pass on "the logging
configuration changed" events generated in logback, jcl-over-slf4j
etc.).
2) It's easier to manage if all the logging configuration can be kept in
a single file. The current solution needs two, logback.xml and whatever
file you use for j.u.l.
3) j.u.l. will coexist with other loggers for a long time. Work invested
here will be a benefit for years to come.


So... am I going off into the wild, or am I following a track that SLF4J
would want to be on?

Regards,
Jo

P.S. Implementation support available: I am willing to provide the code
for SLF4JBridgeHandler, but I'm not deeply enough into SLF4J in general
to do the required changes.)

P.P.S.: Personal significance: This isn't an immediate problem for me,
I'll probably get around to setting up a proper j.u.l. configuration
some day (*sigh*).