Early review of std.logger

[Jeremy Powers]

Short version of below:
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.


On Wed, Oct 16, 2013 at 12:30 AM, Robert Schadek <realburner at gmx.de> wrote:

>  no hierarchical logs, KISS just create a logger with different
> destination. new FileLogger("myDevLog"); $ tail -f myDevLog
>
>
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.

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.


 Configurable log ouput with custom fields (time, thread, etc).
>   - required for making log output match predefined formats
>    - include needed metadata in the log line
>
> 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.
>

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.

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.

MDC in slf4j/logback is one approach to the 'information included' problem:
http://logback.qos.ch/manual/mdc.html

Not suggesting std.logging needs the same thing, but illustrates one way to
solve.  Personal experience has shown this is useful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131016/f194a6ad/attachment.html>