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