<div dir="ltr"><div>Short version of below:</div><div>I want a powerful logging system.  Maybe std.logging should provide the interface with some basic functionality, allow other solutions to fill in gaps.  Should be able to always code against std.logging, complications added as needed w/o code calling log() caring or changing.</div>
<div><br></div><div><br></div><div>On Wed, Oct 16, 2013 at 12:30 AM, Robert Schadek <span dir="ltr"><<a href="mailto:realburner@gmx.de" target="_blank">realburner@gmx.de</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div class="im">
    <div>no hierarchical logs, KISS just create a logger with different
    destination. new FileLogger("myDevLog"); $ tail -f myDevLog</div></div><div class="im"><br></div></div></blockquote><div><br></div><div>Without this provided out of the box, I'd have to create my own framework for such on top for any serious use.  This is arguably the most important feature of a logging framework for a large product.  Once you get multiple people/teams/companies/monkeys contributing to a system, you _need_ a way to distinguish and filter logging from each part.  Spitting to different log files is not a solution in most cases, the 'create my own' would have each module logger spitting to the same place as the root, with the root logger controlling what actually made it to the log.</div>
<div><br></div><div>Simple logging framework should be simple.  But it should also be powerful, without requiring custom boilerplate for more complex usage...  Earlier was mention of getting a module's log via import, this seems a good solution interface wise - basic implementation would just return basic logger, but would allow for a hierarchical solution to be plumbed in without the logging code knowing/caring.</div>
<div><br></div><div><br>
        </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="im"><blockquote type="cite"><div dir="ltr">
        <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>
    </blockquote></div>
    I think this has been discussed twice already, no configuration can
    anticipate all possible needs and will fail fast and hard. So why
    try, I rather write 7 lines, than wait for a patch to the
    configuration parser to appear in my production env. <br></div></blockquote><div><br></div><div>There are two parts to this: making sure the log output conforms to some format, and making sure required information is included.  You can never anticipate what everyone needs for either, but you can provide the tools to enable them.  Conceptually, this means separating the information being logged from the actual output - the basic logging framework doesn't need to even try to cover every case, so long as it provides hook points.</div>
<div><br></div><div>Once the output is separated from the information, custom output is as simple as a format string.  Important bit is that this is decided by the logger (or whoever configured it) not the code where it is logged.  Can provide basic information by default, or not, so long as there is a mechanism to include custom information.</div>
<div><br></div><div>MDC in slf4j/logback is one approach to the 'information included' problem:</div><div><a href="http://logback.qos.ch/manual/mdc.html">http://logback.qos.ch/manual/mdc.html</a></div><div><br></div>
<div>Not suggesting std.logging needs the same thing, but illustrates one way to solve.  Personal experience has shown this is useful.</div><div><br></div><div><br></div></div>