Early review of std.logger

[Robert Schadek]

On 10/17/2013 04:13 AM, Eric Anderton wrote:
> On Tuesday, 15 October 2013 at 15:16:44 UTC, Andrei Alexandrescu wrote:
>> Eric, could you please enumerate a short list of features of log4j
>> that you think would be really missed if absent?
>
> Certainly.  Here's my top 3, with some background to explain why I
> think they'd be missed.
>
> - Hierarchical logging with a centralized (singleton) logging
> facility.  The strength of this is that it would allow us to freely
> integrate D libraries that use std.logger, yet filter their log output
> from *outside* the library through the std.logger API. This can be
> accomplished by tagging each log event with a category name.  Log
> events are then filtered by prefix matching of the category name, as
> well as by log level.  Without this feature, library authors would
> have to provide explicit API calls to manipulate their library's
> logging, or require API users to pass logging contexts forward to the
> library.
With the new MultiLogger and names for Logger, I consider this done.
>
> - Configurable output strategies for each log category.  In log4cpp,
> these are known as "appenders."  Appenders need not be registered
> explicitly for each category, but can be registered by category name
> prefix match, just like the filtering for the hierarchical system
> (above). The idea is to allow for different formatting strategies and
> output targets, including the logrotate issue I mentioned earlier. 
> This provides a nice integration point to tackle basic capabilities
> today, like file logging and syslog support, and more advanced
> features by 3rd party authors.
>
> - Nested Diagnostic Context support ("Mapped Diagnostic Context" in
> log4j).  The NDC facility in log4cpp/log4cxx is incredibly handy for
> cutting down on the amount of data one usually puts into a given log
> event.  The gist of an NDC is just a way to bracket a series of log
> calls with a prefix that is emitted with the rest of the log line. 
> These contexts are maintained on a thread-specific stack, such that
> each log event is prefixed with all the information in the entire
> stack, at the time of the event. Without this, one winds up
> re-inventing the concept (usually poorly) to forward the same
> information to each call to emit a log message.  It also eliminates
> the need for a stack trace in a log message in most cases, which is
> something that people who use SIEM software (e.g. Splunk) would
> appreciate.
>
> There are other things that would be nice - configuration file
> support, lazy evaluation of log event arguments, custom output formats
> - but I think the above is really core of what's needed.
IMO, this is to heavyweight and would water the current design to much.
That being said, I think it is easy to subclass Logger or MultiLogger to
achieve this. But I don't think that this should be part of the default
feature set.