Bugzilla – Full Text Bug Listing
| Summary: | [runtime] API: Have written to log file? | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | DJ Houghton <dj.houghton> |
| Component: | Resources | Assignee: | Platform-Resources-Inbox <platform-resources-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | dejan |
| Version: | 2.0 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
DJ Houghton
Recommendation: /** * Returns <code>true</code> if the platform logfile has been written to * in the current session, and <code>false</code> otherwise. * * @return whether the log as been written to yet during this session * @since 2.0 */ boolean Platform.hasLogged(); I would like to understand more about the PDE problem to be addressed here. Is the problem with PDE interrogating the log of the target Eclipse launched by PDE? If yes, then why doesn't PDE just delete the log file from the runtime workspace before re-launching it? PDE has a view called 'Log View'. It was originally designed to help plug-in developers better handle core exceptions thrown by the platform as a result of irregular behaviour of plug-ins under development. Strictly speaking, Log View is a luxury more than a necessity - it is much easier to look at a view than locating the .Log file and looking for entries. This is particularly true for new developers. Log View was designed based on Microsoft's 'Event Viewer'. The major missing feature in the Log View is that it only handles log entires fired after it was opened. Therefore, it completely misses entries previously logged, including entries during startup. For this reason, PDE will now include a capability to 'sync up' with the log file by parsing it and converting entries into objects in the view. Unlike with the real log file, Log View also allows users to clear it to be able to easly spot entries caused by their plug-in. The problem PDE faces with the new format is that it only cares about the current session, and it cannot tell if the last session in the log belongs to the currently running instance. Although Log View was initially designed to run in a run-time Eclipse instance only, it is simple and generic enough to be used in the design-time instance as well (as a more user-friendly alternative to locating the log file manually). I see how the "Log View" would be generally useful for viewing the log of design-time instance. The fact that the log now grows forever makes the "Log View" even more useful. But in this situation, I don't understand why you say that "PDE [...] only cares about the current session". A user looking at the log would be interested in all log entries - to know if they had experienced problems in past sessions as well as in the current session. If that's true, then PDE simply shows the user the entire contents of the log. Each entry is timestamped - so the uses can tell when the entries were added. The statement mostly applies to Log View used in the contest of plug-in development. There you only care about entries created in the running instance (possibly including those in the startup). Expanding role of Log View from plug- in development to a general Log file view, the requirement to see previous sessions becomes valid. So my requirement to be able to tell if the last session in the log belongs to the currently running platform (by asking 'hasLogged()') does not apply to the general case but to the plug-in development scenario where errors from the previous invocations are of not importance. Dejan, is this still required/desired? Closing. Please re-open if this is still required. |