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.
Debugger stops at first line in debugged jsp when you reload page in browser. To reproduce: - create new web application - add breakpoint to index.jsp (e.g. line 18) - start debugger (F5) and wait until it stops at breakpoint - continue step by step using F7 (step into) action - once you reach end of index.jsp, go to browser and reaload the page. Debugger stops at first line in index.jsp Build 200510111800, WindowsXP, JDK1.5.0_05, Bundled Tomcat.
It is not problem of JSP debugging. The problem is that action 'step into' (F7) or 'step over' (F8) is planned but not realised in the current pass because current execution leaves JSP/Servlet code and continues somewhere in non-debuggable servlet container's code. Simply no place to make the required step is found. The next run then finds the first possible place to stop - and this is the first line of the JSP/Servlet code. Thus debugger stops the execution and annotates the first line. Steps to reproduce it with JPDA debugger only: 1. create web app, let's say WebApp 2. create servlet, let's say NewServlet 3. go to NewServlet's doGet() method 4. add some line(s) of code above and below processRequest() call (it should be originally at line 48) 5. set breakpoint at the last line in the doGet() method 6. debug web project - browser is opened with url http://localhost:8084/WebApp/ 7. modify the url to http://localhost:8084/WebApp/NewServlet and hit <enter> 8. execution is stopped at the last line (at the breakpoint) in the doGet() method 9. perform step over/into until execution leaves the doGet() method 10. reload the browser Execution is stopped at the first line of the doGet() method. I am not sure about the correct solution, whether we want to fix if it is possible at all -> reassigning to Martin from JPDA debugger
It is too late to fix this in promo-F, it can be considered for next release.
Changing TM for open issues.
Likely caused by smart-stepping, it looks like a symptom of issue #54485.
This can be reproduced also using steps from issue #54485 but doing Step Into instead of the last Step Over.