Community
Participate
Working Groups
The strategy for creating contexts from stack traces that was initially implemented iterates over the stack trace and generates an artificial selection event for each identified Java element. A basic filter that excludes known system name spaces such as java or junit.framework helps to reduce the number of irrelevant elements. Still, this strategy can lead to large contexts with elements that have little relevance to investigation the problem captured in the stack trace. This task is intended for discussing improvements.
One idea that was suggested on the call today was to assign a high interest to the top element and linearly decrease interest processing the stack trace top to bottom.
How do you access this feature?? The linear decrease makes sense for a lot of cases, but there are other cases where the interesting stuff is somewhere in the middle of the stack trace.
If you activate a task with an empty context that has a stack trace in the description or in the new comment the context is automatically generated.
Cool, I never noticed that. It would be useful to also auto-populate the call hierarchy view based on the stack trace.
In fact if we did that, we might not want to auto-populate the context at all.
(In reply to comment #1) > One idea that was suggested on the call today was to assign a high interest to > the top element and linearly decrease interest processing the stack trace top to > bottom. It might be useful to provide framework-aware filters. For example, common frameworks (Such as Spring Framework, Java EE containers such as JBoss, etc.) apply aspect oriented filters to method calls in order to apply transactional semantics, security, logging, etc. Unless you're specifically working on these frameworks, these items are usually irrelevant within the context of an application development task. For such filters to work, awareness of package namespaces and fully qualified class names is needed. Some profilers use this approach to filter unwanted classes/methods from profiling data. We could get smart and filter packages for which there is no source in the workspace.
(In reply to comment #5) > In fact if we did that, we might not want to auto-populate the context at all. -1 In my opinion, the task context is much more powerful and it's orthogonal to the view you're using (it can apply to any view that supports filtering by context).
(In reply to comment #7) > (In reply to comment #5) > > In fact if we did that, we might not want to auto-populate the context at all. > > -1 In my opinion, the task context is much more powerful and it's orthogonal to > the view you're using (it can apply to any view that supports filtering by > context). The problem is that currently the whole stack trace goes into your context. I would like to be able to select specific methods in the trace or call hierarchy and have only those in my context. The current approach is a bit like have the context for a new task contain everything instead of nothing.
...but I do see your point that context population is powerful. The trick is to have an intelligent way of limiting what goes into it; I like your suggestions above but don't know if that will limit it enough.
(In reply to comment #8) > The problem is that currently the whole stack trace goes into your context. The current implementation adds the top 10 elements from the stack trace, since stack traces can be very large. > I would like to be able to select specific methods in the trace or call hierarchy > and have only those in my context. The current approach is a bit like have the > context for a new task contain everything instead of nothing. Yes, this would be useful. An advantage of the current implementation is that no user interaction is required. To get specific methods in the context, you can click on them in the task editor (they're hyperlinked). Also the context can be pruned and landamarks created using the normal affordances.
Created attachment 198238 [details] mylyn/context/zip
The current strategy has some bugs. When activating a task with no context, it was prepopulated with classes named Plugin, Product, Severity, and Date, and methods named error, because these words appear somewhere in a comment with a stack trace. Also, when populating with classes that are in the plugin dependencies of multiple projects, the choice of projects to add to the context seems to be arbitrary, and multiple projects were added for different dependencies, even though they could all have been found under the same project.
(In reply to comment #12) > The current strategy has some bugs. Sam, please file a separate defect for problems associated with the current implementation. If you can, include the stack trace that is problematic.
I've created the following: 354184: context from stack trace population includes irrelevant items https://bugs.eclipse.org/bugs/show_bug.cgi?id=354184 354185: context from stack trace population should minimize the number of projects added to context when adding plugin dependencies https://bugs.eclipse.org/bugs/show_bug.cgi?id=354185
(In reply to comment #10) > The current implementation adds the top 10 elements from the stack trace, since > stack traces can be very large. For a stack trace that begins with the following, this is exactly the wrong approach! java.lang.reflect.InvocationTargetException at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:421) at org.eclipse.jface.dialogs.ProgressMonitorDialog.run(ProgressMonitorDialog.java:507) at org.eclipse.ui.internal.progress.ProgressMonitorJobsDialog.run(ProgressMonitorJobsDialog.java:275) at org.eclipse.ui.internal.progress.ProgressManager$5.run(ProgressManager.java:960) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.ui.internal.progress.ProgressManager.busyCursorWhile(ProgressManager.java:995) at org.eclipse.ui.internal.progress.ProgressManager.busyCursorWhile(ProgressManager.java:970) at org.eclipse.ui.internal.progress.ProgressManager.run(ProgressManager.java:1166)
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
