LiveLabs Logging Version 1.0

Rating: No reviews yet
Downloads: 600
Released: Feb 11, 2009
Updated: Mar 9, 2009 by justrudd
Dev status: Stable Help Icon

Recommended Download

Source Code LiveLabsLogging-src-1.0.zip
source code, 869K, uploaded Feb 12, 2009 - 356 downloads

Other Available Downloads

Application LiveLabsLogging-bin-1.0.zip
application, 38K, uploaded Feb 12, 2009 - 173 downloads
Application LiveLabsLogging-signed-bin-1.0.zip
application, 38K, uploaded Mar 9, 2009 - 71 downloads

Release Notes

LiveLabs Logging 1.0 is the culmination of changes from 0.1 in May 2008 till January 2009. This is not backwards compatible. You will have to make some changes.

The Configuration class is gone and been replaced with a Settings class. The Settings class is not a singleton class. Multiple instances of it can be created and used. If you do not create one, a Default one will be used. This was introduced to allow common settings to be shared between loggers that weren't in the same hierarchy.

RollingLog was renamed to TimedRollingLog to better described what its function is. The other major change for this class is naming of files. In 0.1, the file was not changed until it needed to roll. So if the name was "my_log.log", RollingLog would write to "my_log.log" until the time came to roll. Then it would create a time an hour in the past and move the file to that new name. And then reopen "my_log.log". In the Unix world, this works even if someone is "tail -f my_log.log". But in Windows this didn't work. And unfortunately, I never hit the bug in testing, but someone did and it crashed horribly. In TimedRollingLog, the base file name will never be created. A date will be immediately appended to the file. So "my_log.log" would be "my_log.log.2009-02-11-14". This also solved another edge case where a buggy program crashed before the roll date, and then got started up AFTER the roll date. The file "my_log.log" could grow unconstrained.

One major change is that all Log implementations are not threadsafe by default. There is a decorator called LockingLog that will make any Log implementation threadsafe. This way Log implementations that are inherently thread safe already (i.e. EventLog, System.Diagnostics.Trace, System.Console.Error, etc.) do not have the locking overhead for no gain.

To get thread-safety, simply do this...
Settings.Default.DefaultLog = new LockingLog(new TimedRollingLog("my_log.log"));

As with all projects, I am currently writing the documentation. I'll update the main site when available.

Reviews for this release

No reviews yet for this release.