Reputation: 3216
1) Breaking where it shouldn't: In tools > options > misc > java debugger > step filters, I have "Do not step into" set to synthetic methods (checked), static initializers (checked), and added entries for classes matching java.*, java.util.AbstractExecutorService, and java.util.ThreadPoolExecutor (redundancy in the pursuit of overkill).
Despite this, the debugger always breaks at java.util.concurrent.ThreadPoolExecutor$Worker.run(). I have tried this both with "Step through the filters to reach unfiltered code" checked and cleared.
2) Not breaking where it should: In a GWT MVP project, I have set breakpoints in a Presenter, and they no longer trip (used to). Server RPC breakpoints trip just fine, and I don't see any changes that would cause changes in the way client side code is treated. FWIW, I have the gwt4nb plugin installed & activated.
Any ideas on where to look for the problems behind these behaviors?
Update: It seems that NetBeans really doesn't like using GWT version 2.2. With the following in the pom...
<gwt.maven.plugin.version>2.2.0</gwt.maven.plugin.version>
<gwt.version>2.2.0</gwt.version>
...the Project -> Properties -> Frameworks doesn't even show GWT. If I manually add GWT, it adds the following nodes to the project properties (oddly, it does not replace the existing GWT version node):
<gwt.version>2.0.3</gwt.version>
<runTarget>welcomeGWT.html</runTarget>
The project properties dialog doesn't offer any configuration options for the GWT framework. I still haven't found a way to get 2.2.0 to stick, and I think this is contributing to the client-side debugging problem.
Upvotes: 1
Views: 708
Reputation: 1113
The typical problem is that the code being stepped through (compiled) code does not match the source code in the project. If I update some source code and save it, and then step through a deployed project in the debugger, I can produce the same behavior.
Upvotes: 1