Community
Participate
Working Groups
I ran into this originally in a more elaborate plugin development scenario on 2.1.1. However I can reproduce it with 3.0 M5 as well. Here are the steps: 1. Create a simple java project with one class and a main method. 2. Set a breakpoint in the main method. 3. Create a launch configuration of type application 4. debug and observe how the breakpoint is hit correctly 5. refactor the project's name. 6. Go into the debug debug perspective. There will be exceptions in the .log file or ErrorLog window.
Created attachment 7069 [details] Logfile containing exceptions This is from the original situation, repeated twice.
Could not reproduce problem. It looks like the breakpoints view was attempting to render a breakpoint that no longer exists. When I try this, the breakpoint is removed as expected (when a project is renamed). We intend to improve this with refactoring support in 3.0, such that the breakpoint remains. However, I did remove unecessary logging of exceptions from BreakpointUtils and JDIModelPresentation.
Please verify, Darin (S).
I can reproduce the problem on 20031209..the breakpoint is not removed. With the changes nothing is logged to the Error Log but I am now left with a breakpoint that has as a label "<not responding>". Investigating.
Good - that you can reproduce it (and that label is expected in the case of a missing type). However, the breakpoint should get deleted.
There resource change listener which leads to the element changed notification is for post change. We are only post auto build. So we get told about the Java types that have been deleted before the auto build has completed and before we have loading the breakpoints for the project that has just opened (and has the marker with the old type handle).
The problem is with the project rename. The change notification has changed somehow. When you rename a single compilation unit, breakpoints are cleaned up fine (i.e. auto-deleted). The same used to happen with project renames. I could not find a simple fix for M6. The side effect is that you have to manually delete the breakpoints yourself (from the breakpoints view). Marking as a dup since this will just be replaced by refactoring support, rather than a fix (see bug 7552). *** This bug has been marked as a duplicate of 7552 ***