Issue2778

classification
Title: Use Java logging framework
Type: rfe Severity: normal
Components: Core Versions:
Milestone:
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: jeff.allen
Priority: normal Keywords:

Created on 2019-06-20.08:00:01 by jeff.allen, last changed 2019-06-20.08:00:01 by jeff.allen.

Messages
msg12560 (view) Author: Jeff Allen (jeff.allen) Date: 2019-06-20.08:00:01
We should use a standard way to issue log messages, preferably plain Java logging.

Motivation:

1. In several pieces of work over the last year or so I have wanted to insert logging instructions (Py.writeDebug() etc.) but have been deterred from doing so, or from leaving them in place for production, because the cost of creating the messages is borne whether they be issued or no. Modern frameworks are lazy: the message is formatted only if it will be emitted.

2. Start-up time, and performance generally, is a worry, and I think it would help us get a grip on it to be able to issue messages with a time stamp, probably at millisecond resolution. We can easily turn this on using Java logging.

3. Using a standard approach gives our users a control mechanism they (probably) already understand if their application uses logging at all.

Implementation:

I propose to use the plain Java logging framework since it does not add another JAR, appears adequate for our needs, and messages can be diverted by application builders into whatever enterprise framework they use.

We can introduce this inside the current logging methods (Py.writeComment() etc.) with minimal code change, then progressively introduce Java logging in place of such calls to get the laziness advantage. I believe we can arrange to produce messages by default only when we currently produce them. There would be differences in detail in the format and names for levels, and that they would emerge by default on syserr.
History
Date User Action Args
2019-06-20 08:00:01jeff.allencreate