This project has moved and is read-only. For the latest updates, please go here.
3

Closed

File Logging Provider

description

It would be nice to include a File Logging Provider with the basic package too. You've already got example code listed on the site so why not just include it with the downloaded code too? Thanks for the logger!
Closed Aug 13, 2010 at 10:54 PM by dot_NET_Junkie

comments

dot_NET_Junkie wrote May 1, 2010 at 5:48 PM

Thanks for adding this issue. I will consider adding a file logging provider to a future release of CuttingEdge.Logging.

Please note that the example code for the file logging provider on the home page is too simplistic to be included in the framework. For instance, it doesn't do any security checks on that file on startup to check whether it is allowed to write to that file/location, and it can fail in a multi-threaded environment (such as ASP.NET) with an IOException, because the AppendAllText will put an exclusive lock on that file while writing.

Writing such a logger is much more work than just taking that example and putting it into the framework. Besides this, there are some design decisions to be made about such a logger. For instance, should the logger take an exclusive lock on the file to use for the lifetime of the application, or should close the file after each write? Should the logger be able to handle when multiple processes use that same file for logging? What information should the logger write and in which format should it write that information? The example from the homepage isn’t suited to be read by an other program for analysis, because it doesn’t encode line breaks and tabs properly. Perhaps XML is a better format, but proper XML need one single root element, which makes it unsuitable for appending text.

If you, or anyone for that matter, has and ideas about this, please let me know.

Puhn wrote May 2, 2010 at 5:06 PM

For my purposes, I was just using it to dump out some intermediate information for temporary debugging use so those issues didn't apply to me.

I think, because of the issues that you have listed, file logging should not be used for robust logging. At work we use J2EE and java's built in logging mechanisms. However, we write everything to a DB2 table so DB2 can take care of the issues that you mentioned (security, locking, multi-threading).

Maybe it should be named SimpleFileLogging so it is more obvious that it is only for simple logging.

wrote Jul 21, 2010 at 6:45 AM

wrote Aug 8, 2010 at 8:43 PM

wrote Aug 8, 2010 at 8:44 PM

tarekjajeh wrote Aug 9, 2010 at 8:43 AM

if it going to be used in a single application then small modification can be applied which make it usable: a CSV format and some enhancement to the file name can be added and it can be used, the exmple is so simple but it can be utlized.

dot_NET_Junkie wrote Aug 9, 2010 at 1:47 PM

I'm currently thinking about a provider implementation that has the following behavior:
  1. Appends events in an XML format to a file.
  2. This log file that will be appended will not have a single root node.
  3. The logger will not hold an exclusive lock on the file but will close the file directly after writing.
  4. Within the same AppDomain multiple threads can use the same or multiple instances of this provider to log to the same file without any issues.
  5. The provider might fail to write to the log file when another process or other code in that same process/AppDomain takes a lock on that file. The FallbackProvider mechanism of framework allows handling these type of failures.
  6. The logger will write event time, severity, source and exception information to the log. The exception information will be the message, stack trace and possible inner exceptions.
  7. The logger will have an extendibility mechanism that allows users to add custom log events (by inheriting from by class).
The logger will write entries in an XML format to the log file, but the log file itself will not be valid XML, because it will not have a single root node. It is impossible for that file to have a single root node, when we’re only appending text to the log file. This invalid format can cause problems supplying the log file to an application that should parse the log file. A workaround for this problem is to write a new valid XML document that references that log file using an XML entity. I’m considering to add a description of this workaround to the documentation.

The provider can fail when another process has a lock on this the log file. While inter process communication can fix this, this will only solve the problem when those multiple processes all use that same provider. It will not help you when multiple machines write to a network share or when other types of applications write to this file. This is a hard to solve problem in general. Therefore it would be better to let only one single application (or AppDomain) write to that file.

I’m interested whether you think such an implementation would be workable.

wrote Aug 10, 2010 at 12:09 AM

Puhn wrote Aug 10, 2010 at 12:15 AM

Is there any reason for the XML format? I was thinking more of a simple, human-readable format. Maybe that could be an option; XML format or String format.

dot_NET_Junkie wrote Aug 10, 2010 at 7:08 AM

I choose XML because this is a both human readable and machine reable format. The current implementation uses indentation and writes every element on each own line. In my opinion this results in a pretty readable format, but I like to have your opinion about it. Please check it out as soon as I publish a beta and let me know.

wrote Aug 13, 2010 at 10:54 PM

Resolved with changeset 54058.

wrote Feb 13, 2013 at 7:30 PM

wrote May 16, 2013 at 2:56 AM

wrote Nov 29 at 9:01 AM