groundwork icon indicating copy to clipboard operation
groundwork copied to clipboard

Logging configuration improvement

Open ubmarco opened this issue 8 years ago • 0 comments

The logging configuration might need improvement. Current situation Groundwork registers the following loggers:

  • groundwork
  • groundwork.signals
  • groundwork.pluginmanager
  • groundwork.patterns.gw_commands_pattern (from the commands pattern)
  • groundwork.patterns.gw_documents_pattern (from the documents pattern)

For each plugin, a separate logger is created by groundwork. Its name is the plugin self.name variable. The variable is set to the plugin class name if it's not actively set by the developer.

Now, to get the logs of all plugins, I have to create an own 'loggers' entry in the app configuration.py file for each plugin, which is a bit tedious. The groundwork loggers can all be catched by a single 'groundwork' entry in the loggers dictionary. It's a wildcard for the whole groundwork.* namespace.

New idea Commonly it makes sense to have the same log handler and log level for all my plugins. I propose to introduce a new configuration.py magic variable called LOGGER_APP_NAME. It will be used as application logger name and as a prefix for the plugin logger names. So to set the logger for my app, I need to add a logger like this:

'loggers': {
    '<LOGGER_APP_NAME>': {
        'handlers': ['console_stdout'],
        'level': 'DEBUG',
        'propagate': False
    }
}

It would handle all plugin loggings as well. To set a specific logging for my plugin, I would need:

'loggers': {
    '<LOGGER_APP_NAME>': {
        'handlers': ['console_stdout'],
        'level': 'DEBUG',
        'propagate': False
    },
    '<LOGGER_APP_NAME>.<PLUGIN_NAME>': {
        'handlers': ['console_stdout'],
        'level': 'DEBUG',
        'propagate': False
    }
}

The implementation idea would not brake the current groundwork API.

ubmarco avatar Jul 27 '17 09:07 ubmarco