[logback-dev] Better introspection into logging setup

[Ceki Gülcü]

On 02/03/2010 12:12 PM, Gunnar Wagenknecht wrote:
> 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.

Well, since neither j.u.l. nor log4j frameworks have any knowledge of
SLF4J (which is quite unfortunate in the case of log4j), including
such an interface would have no impact as jul nor log4j would
implement it.

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

Given my past experience it's just not going to happen any time
soon. It would be nice if log4j or jul were SLF4J-aware or took the
SLF4J API into consideration but they don't.

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

Although you have a point about SLF4J loggers having a "notion" of
levels, there is no SLF4J API to set or get levels of the logging
backend. The SLF4J allows for checking whether a given logger is
enabled for some level, but you can't actually get the level of a
logger nor can you set it.

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


I think this problem can not be dealt with abstractly for all
backends. However, if one assumed logback as the backend, some
jul-bridge related code could listen to changes in logback and mirror
them in jul. Such a listener could be enabled as part of logback
configuration. Nevertheless, the home for such code would be in
logback-classic and not SLF4J.

> -Gunnar
>