Perhaps he meant this site? http://jakarta.apache.org/avalon/logkit/
Walt Ritscher -----Original Message----- From: dotnet discussion [mailto:[EMAIL PROTECTED]] On Behalf Of Justin Harrell Sent: Friday, April 19, 2002 1:52 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] Generating XML Log Files What is Logkit.net, Google turns up nothing. Also I implemented my own mechanism in less than an hour and it only takes a few lines of code to implement, so what advantage would I get from Logkit.net? Justin -----Original Message----- From: Nantz, Brian [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 4:41 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] Generating XML Log Files Why not use Logkit.Net and implement your own XML formatter? -----Original Message----- From: Justin Harrell [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 2:18 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] Generating XML Log Files While working on my own project I too wanted to use XML for logging. On eissue is of course you would not want to use a in-memory dom model and save the entire log on every modification, as that technique would not scale as the number of entries became more than a few. The other issue with xml logging and using something like XmlTextWriter is that your must always have a closing tag to be well formed, so that if the log is in use and you don't do anything special your log will not be well formed until your logging process stops and you close the root tag, and then you have an issue of reopening the tag and adding to it later. There are a few solutions, one is to not make well formed xml, that is don't make a root tag and then the logging process becomes just like writing delimited text files, but to read it in as xml you must somehow add the root tag to it first. I ended up creating my own textstream and pointing the XmlTextWriter to it, instead of having XmlTextWriter do one under the covers, then after each log entry I inject the closing tag into the stream, then before making another entry I reposition the stream back the number of bytes that the closing tag is (along with whitespace) and then write some more XML with XmlTextWriter therefore overwriting the last closing tag in the stream, this seems to work well and always keeps a well formed xml log in place after every entry and doesn't use a heavy in-memory dom to do it. One thing to remember is that if your log may be high volume xml is probably not the best format because of how much space is wasted with metadata. But the flipside is you can parse and scan logs with relative ease in your own application code with XmlTextReader. Justin -----Original Message----- From: Smiley, Shawn [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 2:19 PM To: [EMAIL PROTECTED] Subject: [DOTNET] Generating XML Log Files I'm currently working on an Application Log File component that we can embed in various applications that we will be building. I would like the Log File component to generate XML based Log files instead of the more traditional plain text log files. The primary reason for this is so that we can embed additional information in the logs in a way that will both be easy to view (open them up in IE and just browse the tree) or work with programmatically. My current thoughts on how to do this is to instantiate an XmlDocument object when the component is created and then as new entries are added to the document, write the whole document out to the hard drive. My problem with this approach is that it seems like there would be a lot of overhead involved in constantly rewriting the entire log file, not to mention the memory usage required to maintain the entire log file in memory. Are there other options for doing this sort of thing that I'm not thinking of? Thanks in advance, Shawn S. Smiley, MCDBA Sr Software Developer/Software Architect Integrated Business & e-Commerce Solutions xwave New England www.xwave.com Augusta * Portland * Lewiston * Portsmouth 193 Middle Street , Suite 401 Portland, ME 04101 P 207 774-2104 x222 * F 207 772-2400 You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
