I would like to ask for opinions about the following feature list, whether they are required by more poeple or projects and how this issue is solved in other projects:
Features
When an error occurs, there should be an option to view relevant errors and the information to be sent to a specified location such as an email address or the development team.
The required features are:
- A listener to recognize that an error has occurred. This listener should include the error log as well as runtime exceptions.
- An ability to filter the listener by different categories such as by
packages or projects, i.e. org.unicase.*, Emf, etc. Depending on the filter, the
UI for reporting the bug appears. - A UI element showing the relevant errors and collected information such as
operating system, java version, and target definition. The collected information should be transparent for the user for privacy reasons. - Sending the collected data to a specified email address, bugzilla or google group
Furthermore you could think about several refinements, which improve the user acceptance such as an aggregation. In case there are many relevant errors, the framework should aggregate them and only ask the user once in time.
I am interested in any feedback on this.


Eclipse Usage Data Collector already does item 1. We have it configured to report back all logged entries of severity warning or error to a central server.
ReplyDelete@JamesB: Are the data public ? Is there a way for a committer to access those logs ? Because it would be very very interesting.
ReplyDeleteWe implemented something very simple for a RCP app. Two things to keep in mind are: 1) Filtering is very important, some bundles generate 'Errors' for expected events which they also handle internally 2) It would be great if there was some way to pickup errors at a very low level, for instance JVM crashes, even if the report is sent the next time the user opens the application. I would love to see at least the basics of such an implementation available as an eclipse supported api.
ReplyDeleteRiena has "Client Monitoring" (http://wiki.eclipse.org/Riena/Getting_Started_with_Client_Monitoring).
ReplyDeleteIt does not *yet* have filtering - but this will probably come. With Enterprise applications that Riena targets, UI notifications and sending emails or posting into groups is not desired. However, it could be done! Instead it uses remote services.
There is already a bug for this: Bug 304544
ReplyDelete