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.
When using Glassfish V2 with a web project breakpoints act very inconsistent. The break points work fine when using Tomcat 6.x however. I have a simple web project which has a Filter class called TestFilter I was using to track down this issue which I'll attach, but one has to work with the code to see the result/issue. In the project you'll see I have a bunch of silly lines in doFilter where I'm setting Strings, and I do this so I can have some places for break points. So, if you try to debug TestFilter against Glassfish V2u2 you can set break points off and on and stop and debug a few times. Eventually some breakpoints will start getting a crack in them and are marked as invalid. The funny thing is the IDE still stops on them. In the output screen it reads something like: LineBreakpoint TestFilter.java : 55 successfully submitted. Not able to submit breakpoint LineBreakpoint TestFilter.java : 55, reason: No executable location available at line 55 in class org.netbeans.tests.testfilter.TestFilter. Invalid LineBreakpoint TestFilter.java : 55 LineBreakpoint TestFilter.java : 55 successfully submitted. which is crazy because it says it can't submit it then it says it did it successfully all from a single click. You can then stop the debugger and start it again and the breakpoints will be messed up. If you have a hard time getting the breakpoints to act up then edit the file when in debug mode by adding some lines, add some if statements with some logic in between, and then try to set some break points. You'll have to do a few some times, but it consistently behaves inconsistent when using Glassfish, and seems to work consistently well with Tomcat 6.x. I am on openSuSE 10.3, using Sun JDK 1.6v7, with Glassfish V2u2. I'll try it out soon on Windows XP SP2 and let you know from there. I'll now attach my simple test project.
Created attachment 70544 [details] Project to use to see the issue
OK, I tested on Windows XP SP2, Sun JDK 1.6_10, Glassfish V2u2. Same issue. 1) I download the project TestFilter.zip onto the computer 2) I opened it up 3) I debugged it 4) I could set and unset break points fine 5) I stopped the debugger 6) I added the following code to the TestFilter.doFilter method after cp6: String cp7 = req.getAuthType(); 7) I then ran debug. 8) I had two messed up breakpoints 1 was on the line with System.out.println(cp) The other was chain.doFilter(request, response); yet both break points would stop. So, one can't really tell by the breakpoints glyphs whether there is a problem or not. I'm not sure if this may be causing some other type issues or not such as performance issues or anything as I have not looked into the logic used for submitting breakpoints to GF. Notice from the debugger console that it tells me some breakpoints are invalid then tells me that it hit them and stopped the threads: Not able to submit breakpoint LineBreakpoint TestFilter.java : 59, reason: No executable location available at line 59 in class org.netbeans.tests.testfilter.TestFilter. Invalid LineBreakpoint TestFilter.java : 59 User program running Breakpoint hit at line 49 in class org.netbeans.tests.testfilter.TestFilter by thread httpSSLWorkerThread-8080-1. Thread httpSSLWorkerThread-8080-1 stopped at TestFilter.java:49. User program running Breakpoint hit at line 50 in class org.netbeans.tests.testfilter.TestFilter by thread httpSSLWorkerThread-8080-1. Thread httpSSLWorkerThread-8080-1 stopped at TestFilter.java:50. User program running Breakpoint hit at line 51 in class org.netbeans.tests.testfilter.TestFilter by thread httpSSLWorkerThread-8080-1. Thread httpSSLWorkerThread-8080-1 stopped at TestFilter.java:51. User program running Breakpoint hit at line 52 in class org.netbeans.tests.testfilter.TestFilter by thread httpSSLWorkerThread-8080-1. Thread httpSSLWorkerThread-8080-1 stopped at TestFilter.java:52. User program running Breakpoint hit at line 53 in class org.netbeans.tests.testfilter.TestFilter by thread httpSSLWorkerThread-8080-1. Thread httpSSLWorkerThread-8080-1 stopped at TestFilter.java:53. User program running Breakpoint hit at line 56 in class org.netbeans.tests.testfilter.TestFilter by thread httpSSLWorkerThread-8080-1. Thread httpSSLWorkerThread-8080-1 stopped at TestFilter.java:56. User program running Breakpoint hit at line 59 in class org.netbeans.tests.testfilter.TestFilter by thread httpSSLWorkerThread-8080-1. Thread httpSSLWorkerThread-8080-1 stopped at TestFilter.java:59. User program running Breakpoint hit at line 64 in class org.netbeans.tests.testfilter.TestFilter by thread httpSSLWorkerThread-8080-1. Thread httpSSLWorkerThread-8080-1 stopped at TestFilter.java:64. User program running Anyways, this is the same result on two different machines, operating systems, and versions of the JDK though I have not tried with a JDK 1.5uX yet. Maybe there are some variations to try with what versions of the JDK for GF and NB, but I think I can wait on that until someone else tries to reproduce the issue.
There is a note in the dup about the GF side of this issue... see http://www.netbeans.org/issues/show_bug.cgi?id=115033#desc39 and http://www.netbeans.org/issues/show_bug.cgi?id=115033#desc41. You may want to download a GF v2.1 build from http://download.java.net/javaee5/v2.1/promoted/ and see it that addresses the problem. Any promoted build that is younger than Nov. 9, 2008 should have the claimed fix. *** This issue has been marked as a duplicate of 115033 ***