Summary: | DCR: need a way to convert the content of the .log file into IStatus objects (1GCI0VB) | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Dejan Glozic <dejan> |
Component: | Resources | Assignee: | John Arthorne <john.arthorne> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | dj.houghton, paulslau |
Version: | 2.0 | ||
Target Milestone: | 2.0 M5 | ||
Hardware: | All | ||
OS: | Windows 2000 | ||
Whiteboard: |
Description
Dejan Glozic
2001-10-10 22:47:57 EDT
Not a committed item on the 2.0 plan. Changing resolution to LATER. Also note that there is discussion about converting the format of the .log file to XML which then can be parsed by PDE or any other tools which are interested. Could you point me to the discussion location? See RFC 003 off the Platform Core team web space on eclipse.org. http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core- home/rfc/0003/index.html Will re-open bug for now and consider changing the file format to XML so clients are able to parse the file themselves. A general concern with these types of problems is that ideally one who writes the file should also read the file (or provide the mechanism to do so). That way, changing the syntax of the file will not immediately break all the readers. What is written into the file are status objects, so a class that reads the file and converts them into status objects again would free you to change the syntax without breaking users. It is also general Eclipse practice to have only one reader for each XML format (as opposed to several plug-ins being in the XML reading bussiness). That said, if parsing XML is the best we can get for 2.0, I would take it :-). What you suggest is basically what I originally proposed, but it was changed after the discussions in the platform core mailing list. I've written a reader for the XML log file, which I will certainly make available to anyone who can make use of it. That is, I would hand off the code as is, not make it part of the core API. The question we didn't agree on in the discussion is how the reader API would look. There was interest in a wide variety of functionality for reading the log (only reading the "x" most recent entries, only reading errors from certain plugin(s), filtering by date, etc). Rather than commit to a large chunk of API for reading at this stage, I think it's better to just publish the DTD and let others do the reading. It's fairly straightforward to implement a SAX parser to pull in the information you need. OK then, just make sure the DTD is current AND you somehow provide notifications when the DTD is changed. Fixed. The log file is now written in XML format. The class PlatformLogReader can be used as a template for implementing log reading functionality. The log file DTD will be published in the near future. Also note that the method Platform.getLogFileLocation() has been exposed so that clients can now know for certain where the log file is located. |