root logger in config file causing duplicated message printed
YongpengFu opened this issue · 5 comments
- Nipyapi version:0.19.1
- NiFi version: 1.11.4
- NiFi-Registry version: None
- Python version: 3.6.8
- Operating System: Windows 10 Enterprise
Description
There are duplicated log messages on the console when I use my own logger after importing nipyapi.
What I Did
I am using the following code snippet to show the output:
import logging
import nipyapi
# Cusomized logger
logger1 = logging.getLogger('myapp.area1')
logger1.setLevel(logging.DEBUG)
console = logging.StreamHandler()
formatter = logging.Formatter('%(name)-12s: %(levelname)-8s %(message)s')
console.setFormatter(formatter)
logger1.addHandler(console)
logger1.debug('Quick zephyrs blow, vexing daft Jim.')
What I am supposed to get is:
myapp.area1 : DEBUG Quick zephyrs blow, vexing daft Jim.
What I end up getting:
myapp.area1 : DEBUG Quick zephyrs blow, vexing daft Jim.
**DEBUG:myapp.area1:Quick zephyrs blow, vexing daft Jim.**
Reason
In nipyapi-->config.py, nipyapi's call to basicconfig has configured 'root' logger to catch events with warning level and above and send them to stderr. That effectively results in every event from every logger being processed.
It is recommended that a library should not configure logging, only the application should do that.
Urgency
This is not super urgent, but it can cause a lot of headache for any developer who is using this package if they want to have their own logger.
You make a good point, it does not currently follow Python best practices.
We could move to the standard NullHandler call in config.py, and then only call basicconfig in the demo scripts perhaps?
I'm going to be honest, I think since you use getLogger(name) everywhere ( even the demo) I think you can just remove that line from config and set the null handler and be done
I'm not even sure you should set the null handler
Actually @ottobackwards is right. You are using getLogger(name) in everywhere, you don't really need a basicconfig in the config file. As a matter of fact, the issue will persist even when you use standard NullHandler, because a new streamhandler will still be created in the highest of the logger hierarchy (basically the root logger).
I opened a PR