5

I want to do something which seems really straightforward: just pass a lot of logging commands (maybe all, but particularly WARN and ERROR levels) through a method in a simple utility class. I want to do this in particular so that during testing I can suppress the actual output to logging by mocking the method which does this call.

But I can't find out how, with ch.qos.logback.classic.Logger, to call a single method with the Level as a parameter ... obviously I could use a switch command based on this value, but in some logging frameworks there's a method or two which lets you pass the logging Level as a parameter. Seems a bit "primitive" not to provide this.

The method might look a bit like this:

Logger.log( Level level, String msg )

Later

Having now looked up the "XY problem" I understand the scepticism about this question. Dynamic logging is considered bad, at least in Java (possibly less so in Python)... now I know and understand that the preferred route is to configure the logging configuration appropriately for testing.

One minor point, though, if I may: although I haven't implemented this yet with this particular project, I generally find "just" tracing the stacktrace back to the beginning of the particular Thread insufficient, and this is what logback does (with Exceptions passed at WARN or ERROR levels). I plan to implement a system for recording "snapshots" of Threads when they run new Threads... which can then be listed (right back to the start of the app's first Thread) if an error occurs. This is, if you like, another justification for using something to "handle" outgoing log calls. I suppose that if I want to implement something like this I will instead have to try to extend some elements of logback in some way.

Bhargav Rao
  • 41,091
  • 27
  • 112
  • 129
mike rodent
  • 10,479
  • 10
  • 80
  • 104
  • 1
    Why do you need that? Sounds like a X/Y problem –  Jan 15 '17 at 20:51
  • Um. For the reason I've explained. Sigh. Do you think this is a stupid reason? If so, please say why. – mike rodent Jan 15 '17 at 20:52
  • I saw your reason, what's wrong with logs when tests are run? Can't you use 2 logs configs a test one and a production one ? –  Jan 15 '17 at 20:53
  • 1
    If you want to mock the logger, that means you're trying to test the logging, because otherwise you'd just provide a logging configuration file to suppress logging. So, *why* are you trying to test logging itself? – Andreas Jan 15 '17 at 20:54
  • Also, I'm sorry, but what is "sthg"? – Andreas Jan 15 '17 at 20:55
  • Ah, OK. Well, for example, when you're doing Unit Tests you want them to run as fast as possible. You don't necessarily want to print out lengthy stack traces if they serve no purpose. Conversely, in an actual run, you want a *maximum* of info about any errors/warnings which happen: not only "immediate" stack traces but even "snapshots" of the stack trace which ran the next Thread... etc. This is time-consuming. – mike rodent Jan 15 '17 at 20:56
  • @Andreas sthg = something (I think). Regarding the question, see http://logback.qos.ch/manual/configuration.html ("logback tries to find a file called logback-test.xml") –  Jan 15 '17 at 20:56
  • @RC. That is my guess too, after a web search. Perhaps in a chat system it would be "something", but here it's just meaningless letters. SO is *not* a chat site. – Andreas Jan 15 '17 at 20:57
  • Andreas, yes sthg = something. I take your point about supressing logging but you can also "mock out" a method because it does something superfluous to the actual test, right? – mike rodent Jan 15 '17 at 20:58
  • @mikerodent If you want the logging statements to do nothing, you provide a logging configuration file that suppresses logging, and if you coded the logging statements right (e.g. used `isDebugEnabled()`), that would be exactly what you're looking for. – Andreas Jan 15 '17 at 20:59
  • @mikerodent Logging statements that are disabled by configuration will not take any time. – Andreas Jan 15 '17 at 21:01
  • Actually, I don't know about you, but one of my main methods for examining and diagnosing failed tests is to slip in little log.infos, which go to stdout, but also to my file-based rolling log (which has the merit of listing things chronologically). I don't necessarily want to suppress logging. – mike rodent Jan 15 '17 at 21:01
  • PS yes, I know about logback-test.xml being looked for first. I just would like to pass the level as a parameter and not have to use a switch command. PPS other logging frameworks offer this, e.g. in Python. – mike rodent Jan 15 '17 at 21:03
  • @mikerodent *Why* are you talking about passing log level as parameter or switch statement? You write the log statement to a specific level, then you configure the logging system to specify whether that logging level for that particular logger should be logged or suppressed. Your code shouldn't do dynamic logging. As RC commented, this seems to be an [XY Problem](http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem), i.e. you're looking at the wrong area to solve your problem, and hence asking the wrong question. Seems you don't understand the power of log configuration. – Andreas Jan 15 '17 at 21:06
  • "Your code shouldn't do dynamic logging". Ah, now we get to the nub. You have a 37k rep and yesterday you solved my problem to do with Enum.class (thanks again!), and I'm receptive to what you say. *Why* should code not do dynamic logging? As I say in the Python logging module you can do this... – mike rodent Jan 15 '17 at 21:10

0 Answers0