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.