This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
[build 200503221900] 1. open attached projects 2. run EnterpriseApplication1 and add web service from WebApplication2 to webservice registry 3. put breakpoints: - on line 36 in srv.NewServlet in WebApplication3 - on line 20 in ws.MyWSImpl in WebApplication2 4. debug WebApplication3 project (WebApp2 sources should be marked as "use for debugging", if not, mark them for use) 5. goto http://localhost:8080/WebApplication3/NewServlet and back to IDE, you're on line 36 in servlet 6. 12x press F7, you're on line 38 in servlet, now press F7 again => you should be on line 19 in ws.MyWSImpl, but you're on line 20 (where is the breakpoint set) 7. press F7 again => you should be again on line 38 in servlet, but the debugger completes the request BTW: You can randomly see no response from debugger for some longer time
Created attachment 21075 [details] enterprise app
Created attachment 21076 [details] web app
I tested it a few weeks ago, there are missing class loaded event or something like this. The event is raised first time when JVM reaches breakpoint, all lines before it are ignored for stepping. Must be explored a little bit deeply. Anyway, the problem is somewhere in JPDA debugger or JVM itself.
Libore, please reevaluate. When bug is evaluated, it should be clear which component is wrong, if the case is a corner case, or covers more general problems (and should be upgraded to P2, moved to different component for evaluation, ...).
WS client thread is other than WS thread and it implies that we are not able to set STEP_INTO/STEP_OVER request to JVM because this request is tied with a thread. There is still possibility to somehow detect 'remote' WS method and set hidden breakpoint to the first line when user performs step-into action. Target milestone set to promo-F.
*** Issue 69092 has been marked as a duplicate of this issue. ***
TM 5.0 -> TBD
Lukas Jungmann and Martin Grebac agreed to close it as WONTFIX because the right solution is hard to find, if it exists at all, and the workaround on the other hand is really trivial.
v.