Early review of std.logger

[Arjan]

On Thursday, 17 October 2013 at 02:13:12 UTC, 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.
>
> - 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.
>
> For what it's worth: my opinions mostly come from my experience 
> in integrating with log4j and log4cpp.  Log4j is a very 
> heavyweight library - I don't think we need anything anywhere 
> close to that nuanced.  In contrast, log4cpp is very small 
> library and worth a look as something that may be a good model 
> for what std.logger could accomplish.
>
> - Eric

+1

I have used log4net some years ago, really liked the the 'context 
logging' feature. (Nested Diagnostic Context support).

I've also used www.panteios.org logging api, liked that approach 
too.