-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to add levels to enabledLevels? #10
Comments
Use the Configurator for the logging back-end! That's what sets which levels are enabled for which loggers in your session. The level settings are stored in a central location mapped to logger names (like The only logging back-end currently supported is log4j (because that's what Matlab ships with), so use the Log4JConfigurator class. Its https://github.com/janklab/SLF4M/blob/master/Mcode/%2Blogger/Log4jConfigurator.m In your case, I think it would be: logger.Log4jConfigurator.setLevels({'foo.bar.baz.MyThing','DEBUG'}); and after that, the debug-level messages should be visible in your Matlab session. |
Thanks for the response; I see that this, with a logger object, works (*) just like you said.
But if you're using the package functions like logger.info() & logger.info(), you don't have a good way to get the loggerobj.name or callerId that loggerCallImpl.m would have used... so if you want to manipulate levels that will affect package functions, I'm not seeing a good way to do that from inside matlab code. That's okay though, I'm okay with using the above instead of package functions. (*) after a minor patch to Log4jConfigurator.m
|
That's intentional! The point of the high-level logging functions is that the code that is calling them logs to a logger with the same name as their class/package. And it defers all runtime logging output configuration to the application or consumer that is mixing all this code together. Logging output by libraries and reusable code is good. But logging configuration is supposed to be left to the final implementer, and SLF4M is designed to actively discourage or prevent log message sources from trying to muddle with logging output configuration. This is a whole long conversation and philosophical argument. BUT! Your patch in your last comment where you change a local variable name from So, maybe this is a quick fix? Or maybe it's a big long architectural discussion. I'm not sure. |
Your comment is making me think... Maybe not. I'm asking here, in case you're interested :) |
It seems my original position is untenable. It's been a week, and I'm not seeing any response to the stackoverflow posting that supports this position:
So now, I am reformed, and I no longer seek to set library default with setLevel. (edit) P.S. I like apjanke's idea (below) that mylib can simply provide examples to assist the author of bigsw in configuring mylib use of SLF4M. |
I don't know that it is. And my view is that it probably shouldn't be, at least by default as a result of loading and initializing the library. IMHO, "configuration" of logging like this - including setting levels, appenders, and so on - should be reserved for the "final implementer", whether that is the offer of "bigsw", or the IT staff of an organization that is deploying bigsw in their environment. It might be nice for mylib to provide some useful configuration settings via examples or tools - like, as examples in doco, or XML configuration files, or as a I think that's how I've seen it work with other logging frameworks and the libraries that use them, except for the logging framework or intermediate library defaulting to a super-simple "output log to console, INFO level for everything" arrangement if no other configuration is supplied, as a "reasonable default". BTW, sorry for my slow response here. It's been a week. Again. The logger "facade" designOh, one other thing to consider is this: When you get a logger object like this using SLF4J or a similar logging "facade" framework (and SLF4M is one of those):
That mylogger is a simple "facade" that is a layer of indirection in front of the actual logging "back-end" library which controls the messages and provides the run-time configurability for setting which loggers are at what levels, and where output goes and in what format. That mylogger object doesn't even have an interface for modifying those "knobs" that control the levels. It serves as a "drop-off" point where you can pass in log messages and say what the logger name and message level that message is. But it intentionally doesn't provide controls for the client code here to control or configure what that logger and its delegates are actually going to do with that log message. SLF4M is a little weird in that it provides a logging facade API like this for log-emitting code to send log messages with. And it also provides an interface for configuring the log4j back-end to tell it what to do with those messages (by setting output levels and destinations). But that's because Matlab doesn't have either of those facilities in the first place, and it was simpler to combine them in one library. Those two aspects of SLF4M are intended to be used by different audiences: the message-sending stuff is for library and application code to use to send/emit log messages, and the "Configurator" stuff is for the final deployer/end-applicat-writer to use to control where those messages end up. I should improve the SLF4M documentation on this front. |
Suppose I'm using the functions...
The info message is output, and the debug message is dropped, as expected.
What statement would I make to change the logging level so that logger.debug() was output instead of dropped?
Likewise, suppose
How to add 'debug' to enabledLevels?
The text was updated successfully, but these errors were encountered: