Bridging Log4J over SLF4J and the lack of Log4J Logger.setLevel()
[Originally posted on 12/26/2012, but it apparently did not make it to the list archives. msp] Hi. Thank you for SLF4J and Logback. I have this line of code that just today came in from an upstream dependency out of my control: private static final Logger logger = Logger.getLogger(FooImpl.class); static { logger.setLevel(Level.DEBUG); <<<<<<<<<<<<<<<< } Unfortunately, this is logging code I had been successfully bridging, but this setLevel() call on a Log4J logger breaks it. Do I have any elegant recourse beyond asking the developers of the line of code to not do this? Thanks. -- Mark
Not really - setting a level is implementation specific, a valid SLF4J implementation might not even allow setting levels on a Logger. A library should not be doing it anyway - what level of messages the end application is interested in doing something with should be the business of the end application, not the library. If it's the end application code that wants to dynamically set the level then that bit of code should be ported to whatever SLF4J implementation you are planning on using. Rob On 7 Jan 2013, at 14:16, Mark Petrovic <mspetrovic@gmail.com> wrote:
[Originally posted on 12/26/2012, but it apparently did not make it to the list archives. msp]
Hi. Thank you for SLF4J and Logback.
I have this line of code that just today came in from an upstream dependency out of my control:
private static final Logger logger = Logger.getLogger(FooImpl.class); static { logger.setLevel(Level.DEBUG); <<<<<<<<<<<<<<<< }
Unfortunately, this is logging code I had been successfully bridging, but this setLevel() call on a Log4J logger breaks it.
Do I have any elegant recourse beyond asking the developers of the line of code to not do this?
Thanks.
-- Mark _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Hi Mark, Assuming the Logger class you are referring is in package org.apache.log4j and by "bridging log4j-over-slf4j" you are referring to the log4j-over-slf4j module shipping with slf4j, then the setLevel() method in Logger is missing. Please file a bug report at http://bugzilla.slf4j.org/ so that this omission can be fixed (with a nop implementation of said method). -- Ceki 65% of statistics are made up on the spot On 07.01.2013 15:16, Mark Petrovic wrote:
[Originally posted on 12/26/2012, but it apparently did not make it to the list archives. msp]
Hi. Thank you for SLF4J and Logback.
I have this line of code that just today came in from an upstream dependency out of my control:
private static final Logger logger = Logger.getLogger(FooImpl.class); static { logger.setLevel(Level.DEBUG); <<<<<<<<<<<<<<<< }
Unfortunately, this is logging code I had been successfully bridging, but this setLevel() call on a Log4J logger breaks it.
Do I have any elegant recourse beyond asking the developers of the line of code to not do this?
Thanks.
-- Mark
Done. Thank you. http://bugzilla.slf4j.org/show_bug.cgi?id=289 On Mon, Jan 7, 2013 at 10:24 AM, ceki <ceki@qos.ch> wrote:
Hi Mark,
Assuming the Logger class you are referring is in package org.apache.log4j and by "bridging log4j-over-slf4j" you are referring to the log4j-over-slf4j module shipping with slf4j, then the setLevel() method in Logger is missing. Please file a bug report at http://bugzilla.slf4j.org/ so that this omission can be fixed (with a nop implementation of said method).
-- Ceki 65% of statistics are made up on the spot
On 07.01.2013 15:16, Mark Petrovic wrote:
[Originally posted on 12/26/2012, but it apparently did not make it to the list archives. msp]
Hi. Thank you for SLF4J and Logback.
I have this line of code that just today came in from an upstream dependency out of my control:
private static final Logger logger = Logger.getLogger(FooImpl.** class); static { logger.setLevel(Level.DEBUG); <<<<<<<<<<<<<<<< }
Unfortunately, this is logging code I had been successfully bridging, but this setLevel() call on a Log4J logger breaks it.
Do I have any elegant recourse beyond asking the developers of the line of code to not do this?
Thanks.
-- Mark
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
-- Mark
participants (3)
-
ceki -
Mark Petrovic -
Robert Elliot