Using glog's design for Phobos?
Bruno Medeiros
brunodomedeiros+spam at com.gmail
Wed Oct 6 10:46:28 PDT 2010
On 27/08/2010 02:34, Walter Bright wrote:
>
> Even worse, the logging libraries are loaded with a grab bag of trivial
> features to try and puff it up into looking impressive. They always
> seemed to me to be a solution in search of a problem.
>
> Shields up! what am I missing about this?
People have already mentioned:
* The need to configure log options dynamically (during runtime), or
by restarting the program (but without recompilation or redeployment).
* Most log analysis occurs with programs running in production, not in
test environments, and as such performance is quite important. That's
why you have log levels and not just a binary on-off option.
Other useful stuff not mentioned already:
* Ability to add log message metadata. That is the ability to log not
only the log message, but associate metadata such as timestamp, date,
current thread, source file location, etc., *in a configurable manner*.
* An extensible mechanism to configure where the log message is sent.
Just outputting to a file or console may not be enough. You might need
to send logs through email, you might need to log them on some OS log
mechanism, etc.. Ideally you should be able to create your own log
message "handlers" (These are called Appenders in log4j lingo).
* Some form of user defined "channels" feature (aka named logs):
associate a log call with some name or "channel" which can be configured
separately from other channels. Usually each channel corresponds to some
user-defined logical module, behavior, aspect or component of the
application.
If your application has a huge number of these, you *will* want the
ability to configure them separately. (again for performance, but also
for easier log analysis) This is common in the Java server world,
consider for example this call stack for a typical webapp using Spring,
a popular Java webapp framework:
http://ptrthomas.wordpress.com/2006/06/06/java-call-stack-from-http-upto-jdbc-as-a-picture/
--
Bruno Medeiros - Software Engineer
More information about the Digitalmars-d
mailing list