XML Logging (Your thoughts)
-
I'm interested in implementing my applications log files as XML. From what little I know of XML, DOM requires that you load the entire document before you can manipulate nodes. Fine for reading, but if I'm logging a lot of items, I don't want to have to open the file, read the entire document, add a node, then close again. Does anyone have any experience doing XML logging? Is it worth the trouble? Got any examples or advice on non-DOM implementations?
-
I'm interested in implementing my applications log files as XML. From what little I know of XML, DOM requires that you load the entire document before you can manipulate nodes. Fine for reading, but if I'm logging a lot of items, I don't want to have to open the file, read the entire document, add a node, then close again. Does anyone have any experience doing XML logging? Is it worth the trouble? Got any examples or advice on non-DOM implementations?
I would not use XML files for logging. They are text files as you state, open and closing all of the time. Some database would be better. You can then always export the database to an XML file when needed for processing or archiving. XML and related technologies are great but they are not pixie dust for all of the worlds troubles. To be conscious that you are ignorant of the facts is a great step towards Knowledge. Benjamin Disraeli
-
I'm interested in implementing my applications log files as XML. From what little I know of XML, DOM requires that you load the entire document before you can manipulate nodes. Fine for reading, but if I'm logging a lot of items, I don't want to have to open the file, read the entire document, add a node, then close again. Does anyone have any experience doing XML logging? Is it worth the trouble? Got any examples or advice on non-DOM implementations?
You could use one of two approaches if you do not plan to read the log file (only write to it):
- You could use the SAX interface to write entries to the log file
- You could write include XML tags in your log messages, making it possible to process the log later with an XML processor
The second option is, by far, the easiest to implement. I wrote an article for another Web site back in November 2001 that covers most of option #1 - here's the link (new window): Using the Microsoft XML Parser to Create XML Documents Essam - Author, JScript .NET Programming
...and a bunch of articles around the Web -
I'm interested in implementing my applications log files as XML. From what little I know of XML, DOM requires that you load the entire document before you can manipulate nodes. Fine for reading, but if I'm logging a lot of items, I don't want to have to open the file, read the entire document, add a node, then close again. Does anyone have any experience doing XML logging? Is it worth the trouble? Got any examples or advice on non-DOM implementations?
here's what I did, but we didn't run this production yet 1) construct one line of valid xml 2) write it to text file , flush buffer This produced a text file that resembled xml, but missing the top-level node. To display it in a web page, I pre-pended a top-level node ( < TOP > ) , and appended a closing node name ( < / TOP > ), and this worked. I think one possible advantage is that it is super fast and simple to write a line of text, and then you can take care of the leading and trailing niceties later when you display the file. Also, this approach ignores the DOM entirely. It is only straight C text files at the time of logging. :rolleyes:
-
here's what I did, but we didn't run this production yet 1) construct one line of valid xml 2) write it to text file , flush buffer This produced a text file that resembled xml, but missing the top-level node. To display it in a web page, I pre-pended a top-level node ( < TOP > ) , and appended a closing node name ( < / TOP > ), and this worked. I think one possible advantage is that it is super fast and simple to write a line of text, and then you can take care of the leading and trailing niceties later when you display the file. Also, this approach ignores the DOM entirely. It is only straight C text files at the time of logging. :rolleyes:
We have done something similar, and for the first time files, if you check their existance before opening them, you can write out the xml header for a new file. You can also write out any trailer information, and if it is static, then when you open the file, you can re-position the file pointer (using fseek) to be that number of characters back from the end, write out your new data, and rewrite the static (ie, fixed/known length) trailer. It's a little clumsy, but it helps to know that you can re-position the file pointer. Dave "You can say that again." -- Dept. of Redundancy Dept.