Message12560

Author jeff.allen
Recipients jeff.allen
Date 2019-06-20.08:00:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1561017601.74.0.81073273061.issue2778@roundup.psfhosted.org>
In-reply-to
Content
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.allensetrecipients: + jeff.allen
2019-06-20 08:00:01jeff.allensetmessageid: <1561017601.74.0.81073273061.issue2778@roundup.psfhosted.org>
2019-06-20 08:00:01jeff.allenlinkissue2778 messages
2019-06-20 08:00:01jeff.allencreate