[logback-dev] Better introspection into logging setup

[Robert Elliot]

This all feels like it's the wrong way round to me.  SLF4J is an api - an interface.  It should have no knowledge at all of the specific implementation.  It doesn't know whether it's juli or log4j or logback or some other logging system I write tomorrow underneath, so how can it enumerate its Loggers?

SLF4J doesn't configure loggers - it just passes a String (or a class) to a method in the implementation that returns an object that happens to implement Logger.  It's purely down to the implementation what it chooses to return from that call and how it configures it.  You could write an implementation that always returns the same "Logger" that always swallows all log statements if you wanted - SLF4J doesn't (and shouldn't) know or care.

Perhaps you are talking about an extension to the jul-to-slf4j bridge?  That would not entail any change to the real slf4j api.

----- Original Message -----
From: "Joachim Durchholz" <Joachim.Durchholz at hennig-fahrzeugteile.de>
To: "logback developers list" <logback-dev at qos.ch>
Sent: Monday, 1 March, 2010 3:53:47 PM
Subject: Re: [logback-dev] Better introspection into logging setup

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*).
_______________________________________________
logback-dev mailing list
logback-dev at qos.ch
http://qos.ch/mailman/listinfo/logback-dev