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.

Bug 148315

Summary:	Breakpoints inconsistent when debugging using Glassfish V2 with a project
Product:	javaee	Reporter:	_ wadechandler <wadechandler>
Component:	Code	Assignee:	issues@javaee <issues>
Status:	RESOLVED DUPLICATE
Severity:	blocker	CC:	vkraemer
Priority:	P3
Version:	6.x
Hardware:	All
OS:	All
Issue Type:	DEFECT	Exception Reporter:
Attachments:	Project to use to see the issue

Description _ wadechandler 2008-09-25 06:50:40 UTC

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.

Comment 1 _ wadechandler 2008-09-25 06:51:41 UTC

Created attachment 70544 [details]
Project to use to see the issue

Comment 2 _ wadechandler 2008-09-25 07:17:49 UTC

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.

Comment 3 Vince Kraemer 2008-10-31 16:19:20 UTC

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 ***