Community
Participate
Working Groups
It is currently possible to register with the platform as a log listener. However, logs that are dispatched are those from the moment of registration. PDE Error Log view needs to show logs that happened before it was opened. An API is needed that parses the current content of the .log file and returns an array of IStatus objects. PDE Error Log could use it to display logs that happened from the moment of the workbench startup. PDE could write a parser itself, but there are two disadvantages to it: 1) PDE does not own the .log file. 2) It is not good to separate code that writes and code that reads the same file format. Since .log file format is private to the Core, it has the privilage to change its format without notice. All PDE cares for is to get an array of IStatus objects. NOTES: JM (06/05/2001 11:19:25 AM) Clarification needed: - What should happen with the exceptions which are dumped to the log? On parsing/reading the log we are not keen on somehow rebuilding the exception objects. - In what form should the returned value be? (Status objects, strings, ...?) Awaiting info... DG (5/6/2001 11:45:36 AM) 1) Of course, it would be ideal if rebuilt status objects would not differ from those logged after the log view has been activated. However, all I really need is the actual stack dump of the exception, not the exception object ifself. If you could create an IStatus implementation that will give me exception text instead of the object, I would be OK. 2) This is related to 1). Error Log works with IStatus objects, so an array of IStatus objects would be ideal. On initialization, Error Log view would ask the Platform to give it all the status objects that have been logged until that moment (including those during the boot). These status object will be shown as the initial content of the view. After that new status objects will be added on top as they are logged. BTW, this feature will allow users to clear the log so that only new status objects are seen as they arrive, but also to restore the entire log. For this reason, the method to parse the .log file and return status objects may be called even during the lifetime of the Error Log view (each time people press "Restore Logs" button). DG (5/9/2001 6:20:34 PM) Info provided, moving to Inbox. JM (5/11/2001 3:04:37 PM) moving to candidates JM (02/06/2001 12:29:43 AM) Deferring for after June
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.
