Community
Participate
Working Groups
If I have several projects open, but only a sub-set of them in the working set, clicking on a file link in the java stack trace console may open a file which is not in the current working set. I would expect that the current window working set is honoured. -- Configuration Details -- Product: Eclipse 1.3.0.20100617-0521 (org.eclipse.epp.package.jee.product) Installed Features: org.eclipse.jdt 3.6.0.v20100526-0800-7z8XFUJFMTfCWGoVuHImpms9H155
(In reply to comment #0) > If I have several projects open, but only a sub-set of them in the working set, > clicking on a file link in the java stack trace console may open a file which > is not in the current working set. So what _should_ happen when you click on the hyperlink?
Sorry for being not precise enough. Here is an example: prj-a/a/b/c.java prj-a-branch/a/b/c.java My working set just contains prj-a-branch. Searching for "c" in Open-Type would return just "prj-a-branch/a/b/c.java" if my working set is enabled and Open-Type is configured to use the window working set. But if my stack trace contains: ... c.java:42 ... then clicking on "c.java" should also open "prj-a-branch/a/b/c.java". But in my case it opens "prj-a/a/b/c.java". Do I miss any configuration, e.g. java stack trace console should use the current window working set or is this really a hole in the implementation?
Any news here? I need some way to relate the "Java stack trace console" to a concrete project if the search returns several locations. Either it should consider the current working set or the window working set or present me a choice to select my project myself. It could be also possible to pin a console to a specific project. As you are more experienced with the Eclipse framework in general, you probably know best how to deal with such a situation in a Eclipse conform way. Please, consider this for 3.7.
(In reply to comment #1) > (In reply to comment #0) > > If I have several projects open, but only a sub-set of them in the working > set, > > clicking on a file link in the java stack trace console may open a file which > > is not in the current working set. > > So what _should_ happen when you click on the hyperlink? If the path is ambiguous, display the different possibities and let me select the correct one. Alternatively, apply the current (Window) working set to restrict the number of cases to select. If there is just one possible selection, choose that one without popup. Would this be feasible to be implemented? To me it happens quite often that I click on a Java Stack Trace link and end up in the wrong file.
Any news on this?
(In reply to comment #5) > Any news on this? We made a bunch of changes in the way we search for classes in bug 138377, would you be able to try a newer version of Eclipse to see if it helps - 3.8.x or 4.3?
removing the security flag - not even sure how that got added...
(In reply to comment #6) > (In reply to comment #5) > > Any news on this? > > We made a bunch of changes in the way we search for classes in bug 138377, > would you be able to try a newer version of Eclipse to see if it helps - > 3.8.x or 4.3? Will try 3.8.0 and update the bug. Thanks, Jörg
This is still an issue in Eclipse Juno.
Any plans to make this work?
(In reply to comment #10) > Any plans to make this work? Nothing planned. If you want to take a crack at fixing it, I would be willing to review patches.
Michael, actually I have no idea where to start looking for this in the code...
(In reply to comment #12) > Michael, actually I have no idea where to start looking for this in the > code... You could start by looking at: 1. the org.eclipse.jdt.internal.debug.ui.console.JavaStackTraceConsole* classes to see how the stack trace console fits together. 2. org.eclipse.jdt.internal.debug.ui.console.JavaStackTraceHyperlink to see how the search is started 3. org.eclipse.jdt.internal.debug.ui.actions.OpenTypeAction to see how the search is performed All of the above code is found in the JDT debug UI bundle, found in the JDT debug repo: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/
Thanks, Michael.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
