How to reproduce the bug:

File|New Project|Samples|Servlet Stateless (Java EE6)|Finish

In Projects window, project ServletStateless|Right click|Properties|Run
Change from "GlassFish Server 3" to "GlassFish Server 3 1"|OK

In StatelessSessionBean.java,
Set a breakpoint on this line:

return "Hello, " + name + "!\n";

In Services Window|Servers|GlassFish Server 3 1|Right click|Stop

In Projects window, project ServletStateless|Right click|Debug

The server starts and the home page displays in the browser.

On the home page, enter your name and click the button.

The NetBeans debugger stops on the breakpoint.

Menu|Debug|Continue.

In StatelessSessionBean.java,
insert lines above the breakpoint:

        if(name != null){
            throw new Error();
        }

Save StatelessSessionBean.java

The breakpint jumps to the first line of code.

The application is redeployed automatically.

Set a breakpoint on every line of code.


An error appears in the Debugger console. The console output so far is:

Attaching to localhost:1121
User program running
LineBreakpoint StatelessSessionBean.java : 39 successfully submitted.
Breakpoint hit at line 39 in class servlet.stateless.StatelessSessionBean by thread http-thread-pool-8080-(2).
Thread http-thread-pool-8080-(2) stopped at StatelessSessionBean.java:39.
User program running
Not able to submit breakpoint LineBreakpoint StatelessSessionBean.java : 40, reason: No executable location available at line 38 in class servlet.stateless.StatelessSessionBean.
Invalid LineBreakpoint StatelessSessionBean.java : 40
LineBreakpoint StatelessSessionBean.java : 42 successfully submitted.

In the browser window, repeat data entry as before.

Expected behavior:

The NetBeans debugger stops on the first breakpoint.

Actual behavior:

The NetBeans debugger skips the first breakpoint and stops on the last breakpoint.

End of testcase.

I found this behavior in more complex applications, but under the more generous condition after I stopped and re-started the debugging session to give the server a better chance for reloading.

So far I do not yet have a testcase for the more generous condition.

But I think that this testcase is very relevant because it reflects what developers actually do with the debugger, and I hope that a fix for it will solve many other cases.