On Tue, Oct 15, 2013 at 8:17 AM, Andrei Alexandrescu < seewebsiteforem...@erdani.org> wrote:
> One note - log4j, log4cxx, and log4cpp are not part of the respective > languages' standards. That doesn't mean much (in fact it may be a > competitive advantage to integrating log4d in std) but it is one factor to > consider. > It also gave rise to slf4j, to tie the various (java) logging solutions together. >From a core library standpoint, the slf4j model might be a good one to emulate - provide a basic logging abstraction that can then be plumbed to whichever logging implementation is needed. Logback is essentially the logging framework written by the slf4j guys, which is why I used it as an example. And though I am not Eric, I do have a short list. These are things that log4j/slf4j/etc provide that I'd consider required of any log framework before I use it in a production* environment: Multiple log destinations (sinks/appenders), configurable. - required for logging to file, syslog, etc as appropriate - different running instances of same code may need different log names/locations/appenders Hierarchical logs, with inheritance of levels, configure at runtime. Turn on/off log level for part of hierarchy. - for debugging own code without being overwhelmed with log statements from elsewhere - turn off extraneous logging in dependencies, or turn it on for deep diving Configurable log ouput with custom fields (time, thread, etc). - required for making log output match predefined formats - include needed metadata in the log line Allow 'lazy' evaluation/formatting of log output (parameterized logging equivalent). - no performance excuse not to log Log rotation - if this isn't there out of the box, guarantee will be first customization * where 'production' is biased towards high availability services