----------------
Rationale
=========
All in all, the `netsvc.Logger` API is pretty pointless: it's verbose —
extremely so when repeatedly using the same channel — it doesn't clearly use
the hierarchical nature of the `logging` package and it doesn't fundamentally
have any advantage over using `logging` raw. Its configurability is also very
limited compared to the options `logging` provides.
Solution
========
But because it's built on top of `logging`, any configuration performed for
`netsvc.Logger ` by OpenERP is actually performed for `logging`, which means
it's possible to use `logging` right now without any issue:
`logging.getLogger('foo').info('bar')` is completely equivalent to
`netsvc.Logger().notifyChannel('foo', netsvc.LOG_INFO, 'bar')`.
Path of evolution
=================
Phase 1 − 5.2
-------------
On calls to `netsvc.Logger().notifyChannel`, issue `PendingDeprecationWarning`.
Because it's ignored by default, this won't change the behavior of the server
unless using `-Wall`, `-Werror` or otherwise explicitly activating the display
of PendingDeprecationWarning. Furthermore, even if activated as long as
`-Werror` isn't used it will simply output a warning message to stderr (by
default).
Strongly suggest that new logging be done via `logging` (by creating custom,
hierarchical loggers), and that if existing logging code (trunk and addons
alike) is touched `netsvc.Logger().notifyChannel` calls be replaced by the
equivalent `logging` calls.
Phase 2 − next(5.2)
-------------------
Replace `PendingDeprecationWarning` by `DeprecationWarning`.
`DeprecationWarning` is enabled by default (nb: except in Python 2.7,
DeprecationWarning is now disabled by default unless using −3) which means it
will appear to all developers unless explicitly silenced. As far as coding
suggestions/standards go, same as phase 1.
Add a "regular" `logging` configuration to the current scheme (using
`logging.config.fileConfig` to allow administrators and users to finely tune
their logging via a logging config file, giving everybody full access to the
`logging` API), optionally enable `logging`'s reconfiguration server (allows
altering the logging configuration of a running system, useful to try to track
issues without restarting the server as long as there is enough logging
performed).
Mark the existing logging command-line switches (--log-level, --logfile,
--syslog, --no-logrotate) as deprecated (issue `DeprecationWarning` when
they're set), introduce a more standard set of log level switches (using
multiple invocations of -q and -v switching between levels, with a default
level of "WARNING" unless ortherwise configured in the logging file, `-vv`
would be equvalent to `--log-level=debug`, `-qq` would be
`--log-level=critical`).
Phase 3 - next(next(5.2))
-------------------------
Remove `netsvc.Logger` entirely, remove the existing python-based configuration
scheme, replace it with an equivalent default logging.conf (logging can
sequentially read several configuration files)
Remove logging configuration from the OpenERP configuration file (it moves
entirely to "logging.conf"), remove the corresponding (deprecated) command-line
switches entirely.
Future usage of logging
=======================
Ideally, there should be far more logging than currently in OpenERP (and with
the finer-grained logging.conf file & conf server it becomes possible to
selectively silence specific loggers and logger hierarchies and dynamically
reconfigure a server instance). Furthermore each object should have its own
logger with the naming form {addon}.{object_name} (which means, among other
things, that the `stock.move` methods redefined in `purchase` would log as
`purchase.stock.move`, not `stock.stock.move`, potentially making debuggings
and post-mortems much easier).
Documentary needs
=================
The coding standard would need to be documented of course (where?), and a basic
documentation for the creation of logging configuration files (as well as a way
to send new configurations to a running server) should be created for phase 2
(the official `logging` configuration isn't bad per se, but it's a bit dense
and aimed at Python programmers rather than e.g. system administrators).
----------------
So, what do you all think of this plan?
--
Xavier Morel
Developper
OpenERP - Tiny SPRL
_______________________________________________
Mailing list: https://launchpad.net/~openerp-expert-framework
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openerp-expert-framework
More help : https://help.launchpad.net/ListHelp
