[slf4j-user] Re: Problem configuring an SLF4J logger

[Heiner Westphal]

Hello Ceki,

Ceki Gülcü wrote:
> 
> Hello Heiner,
> 
> At 05:39 PM 8/10/2005, Heiner Westphal wrote:
> 
>> Sorry for the noise!
>>
>> I plugged nlog4j into my app and will stick to it.
>> Works most of the time.
>> (Not always with maven-cobertura-plugin 1.1, since that expects
>>  a log4j 1.2.8 or .9, stumbling over the Logger.debug(String)
>>  signature).
> 
> 
> There has been some work on the Logger.debug(Object)** signature problem 
> on log4j-dev. In a fortunate ans somewhat ironic twist of events, log4j 
> may end up providing better support for SLF4J than NLOG4J whose raison 
> d'etre is SLF4J compliance.
Not kidding? I asked the cobertura folks on their RFE-forum to upgrade
to nlog4j. Hmmm. Perhaps I should cancel that request.
> 
> If the Logger.debug(Object) signature is too much of a hurdle for you, 
> please shout so that it can be fixed in a future version of NLOG4J or 
> hopefully in log4j itself.
NO! I like the String / String+Object signatures, since they force the
users of the api to follow the "principle of least surprise". They have
to log String messages, no sophisticated logger-Objects which are
smuggled through to some appender, or handler, that knows how to
handle these. One can do this and it may make sense when using
an agreed upon logging framework, but it does not fit with a logging
abstraction like SLF4J.
> 
> ** I assume that maven-cobertura-plugin 1.1 is complaining about the 
> missing Logger.debug(Object) method.
Yes.

> 
>> Should have read the devel messages before...
>> On Sun, 2005-05-01 at 21:53 +0100, robert burrell donkin wrote:
>> [ ... ]
>> > configuration is the most commonly requested feature for JCL. but
>> > implementing it would cross an important line leading to an endless
>> > battle against code bloat and feature drift. explicitly excluded this
>> > possibility in the proposal was definitely the right approach.
>> [ ... ]
>>
>> Though the questions remain:
>>  1. Is there a way to configure an overall log level for the logging
>>     framework sitting under the slf4j API?
> 
> 
> No. There are no provisions in the SLF4J API to allow configuration.
By now I agree this is the only way to keep SLF4J "healthy".
> 
>> Or:
>>  2. Is there a way to figure out which slf4j-Implementation I'm using
>>     at runtime? That way I can implement the switch of level on my own.
> 
> 
> Interesting question. Have you considered casting the returned Logger 
> instance?
No. Have no plan ready now, but wanted to avoid compile-time
dependencies on any logging framework other than simple
(NOP is obviously not an option :).
Hmm, now that I read myself...
This smells like the right starting point for yet another
ClassLoaderNightmare (TM) ;) .

The better approach can be seen at, you guessed it, http://slf4j.org/ :)
The deployer must choose the slf4j implementation and the corresponding
loggingConfig implementation as well.
I think in our case jars consisting of ONE class with ONE static method
setting the level of the "root" logger by String value will do what we
need.

Providing more sophisticated functionality will probably lead to
"code bloat and feature drift".

By providing the right tiny jar for any logging framework,
question 2 from above is obsolete as well, or can be replaced by
"How would a deployment process make sure the loggerConfig and the
slf4jImpl match?"
Else we surprise our users, when they demand log level DEBUG
with log4j but java1.4 logging gets configured with level FINEST
without ever seeing any log record from our app.

Thanks a lot for asking the right questions,

Heiner