<div dir="ltr">On Tue, Oct 15, 2013 at 8:17 AM, Andrei Alexandrescu <span dir="ltr"><<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>

</blockquote><br><div class="gmail_extra">It also gave rise to slf4j, to tie the various (java) logging solutions together.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Multiple log destinations (sinks/appenders), configurable.</div><div class="gmail_extra">  - required for logging to file, syslog, etc as appropriate</div><div class="gmail_extra">
  - different running instances of same code may need different log names/locations/appenders</div><div class="gmail_extra"><br></div><div class="gmail_extra">Hierarchical logs, with inheritance of levels, configure at runtime.  Turn on/off log level for part of hierarchy.</div>
<div class="gmail_extra">  - for debugging own code without being overwhelmed with log statements from elsewhere</div><div class="gmail_extra">  - turn off extraneous logging in dependencies, or turn it on for deep diving</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Configurable log ouput with custom fields (time, thread, etc).</div><div class="gmail_extra">  - required for making log output match predefined formats</div><div class="gmail_extra">
  - include needed metadata in the log line</div><div class="gmail_extra"><br></div><div class="gmail_extra">Allow 'lazy' evaluation/formatting of log output (parameterized logging equivalent).</div><div class="gmail_extra">
  - no performance excuse not to log</div><div class="gmail_extra"><br></div><div class="gmail_extra">Log rotation</div><div class="gmail_extra">  - if this isn't there out of the box, guarantee will be first customization</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">* where 'production' is biased towards high availability services</div><div class="gmail_extra"><br></div></div>