Menu

#2041 revisit Autoplot logging

nextrelease
open
nobody
None
5
2020-02-02
2018-09-28
No

Java's logging has worked wonderfully, and is used exclusively throughout. It's even used in some scripts. However it is inconsistent in some ways.

First ENTER/EXIT should be used, because this reports time and provides an overview of how things are used. I have many logger calls where this is the intent, and I should just use this to standardize this use.

Second, logger names are inconsistent. Sometimes a logger which is too vague is used ("autoplot" vs "autoplot.dom"). I should probably just use the class names, so there is just one set of names for things. I've started adding the constant CLASSNAME to go next to the "logger" declaration.

Third, I should check that no string math is done for loggers, and the templated version is used instead, for performance.

Last, I'm pretty sure some logging stats could be recorded without significant performance problems. I would be nice to be able to sort the loggers by last message timestamp, for example.

Discussion

  • Jeremy Faden

    Jeremy Faden - 2018-09-28
     
  • Jeremy Faden

    Jeremy Faden - 2020-02-02

    Somehow I've just discovered Level.CONFIG. This is less verbose than FINE, but is still turned off by default (the never use Level.INFO rule). This is a useful level because I can log at the interests of the client, who could care less about how a class is implemented. I'd like to log my interactions with a class, so I'd log things like:

    • setProperty(f) which configure the class. I believe this is the intent of the Logging class developers.
    • client-level class use. I'm not so sure about this, but I'll steal the level for this purpose.

    For example, I have a bug where the font size is occasionally not set in the images set by a Jenkins test. I'd like to see that DasCanvas' setFont is called before writeToPng(filename). I think both of these could be logged at Level.CONFIG, since they are both high-level uses of the library.