[logback-dev] Better introspection into logging setup

[Gunnar Wagenknecht]

Am 02.03.2010 11:23, schrieb Durchholz, Joachim:
> 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.

I tend to agree with Joachim. There already is code in "org.slf4j.spi"
to allow logging bridges to better interfere with the logging backend
(eg. LocationAwareLogger). It think it might be a good idea to have some
other API which logging backends *may* implement to allow participation
in the life-cycle of the logging backend, the created/destroyed/modified
loggers.

Something like this:

/**
 * A <code>LoggerEvent</code> listener. <code>LoggerEvent</code> is a
 * listener interface that may be implemented by a logging bridge
developer. When a
 * <code>LoggerEvent</code> is fired, it is synchronously delivered to a
 * <code>LoggerListener</code>. The Framework may deliver
 * <code>LoggerEvent</code> objects to a <code>LoggerListener</code> out
 * of order and may concurrently call and/or reenter a
 * <code>LoggerListener</code>.
 * <p>
 * A <code>LoggerListener</code> object is registered with the Framework
 * using the <code>LoggerFactory.addLoggerListener</code> method.
 * <code>LoggerListener</code> objects are called with a
 * <code>LoggerEvent </code> object when a logger is created, modified, or
 * is in the process of being destroyed.
 * ...
 */
interface LoggerListener extends java.util.EventListener {
 /**
  * Receives notification that a logger has had a lifecycle change.
  *
  * @param event The <code>LoggerEvent </code> object.
  */
 public void loggerChanged(LoggerEvent event);
}


The LoggerEvent indicates the type of change (eg., "MODIFIED") and may
contain additional information (eg. "property 'log.level'"). The
LoggerFactory would simpy pass the listeners to some SPI API that may be
implemented (optionally) by logging backends.

BTW, I do not agree with the argument that the "SLF4J Logger interface
has no inherent concept of a level." Frankly, it has. It is true that
SLF4J does not define what logging backend implementors may do with
these level. However, it clearly establishes the notion of a LEVEL for
SLF4J users through its JavaDoc and the various methods available. This
creates an API contract which SLF4J users /may/ rely on. It also
establishes the concept of enabling and disabling of a LEVEL through
this API. Thus, it's perfectly fine to allow passing modifications of
the enablement state of log levels through the LoggerEvent object.
Implementations not dealing with levels can simply avoid send such
additional information (which could mean NO LEVELS changed).

Having this API as part of SLF4J would allow to have a JUL bridge which
is agnostic of the actual logging backing. But a valid questions
remains, if such API should be added to SLF4J just because of the JUL
bridge.

-Gunnar

-- 
Gunnar Wagenknecht
gunnar at wagenknecht.org
http://wagenknecht.org/