Bug 115033

This is very strange. Can it happen that you have two classes with the same name - CommandViewManager.java ? In
different projects perhaps?
Any details on what is at line 284 in CommandViewManager.java? Could you provide some sample file which we can use to
reproduce the problem?

I found out that if I clear the var/cache/index directory that the problem is temporarily solved. It happens with
basically all my files and it's does not specifically has to do something with CommandViewManager.java. Because I
cleared the cache recently I will have to wait until it happens again. When the problem occurs again. Is there anything
else you need? From the cache as well perhaps?

IT happened again with a different java class this time, called MailManager.java.
I'm not sure if it helps but I solved the problem by removing only one file from the cache:
.netbeans/dev/var/cache/index/0.3/s67/classes/retail/core/MailManager.sig

noot, which build of NetBeans do you use? This looks like a bug in java database. It might be solved in newer builds.
Did you try NB 6.0 beta 1?

I'm using development built 200708300000. I will try the latest.

I have the same error with built 200710071200. It worked fine for a while and after a few debugging sessions it happened
again. BTW I'm debugging mainly by attaching the debugger while the application is already running.

I noticed that just restarting Netbeans solves it temporarily. Beside getting errors and accepting the breakpoints I
also sometime get errors and Netbeans doesn't accept the breakpoints. Then again restarting Netbeans solves it temporarily.

Can you please add -J-Dorg.netbeans.modules.debugger.jpda.level=400 option to netbeans.conf and provide the message.log
as soon as the error occurs? This option will generated some additional debugging info, which can help to identify the
problem.

It looks like this error somehow depends on projects you have opened in NetBeans. Can it happen that you have several
project containing CommandViewManager class? Can you please look into Window/Debugging/Sources and verify that the
source roots are the correct ones there?
Also, which operating system do you have?
Thanks.

*** Issue 116578 has been marked as a duplicate of this issue. ***

Ok, I added de debug level option.

The CommandViewManager class is only part of one project. I sometimes have more than one (open) project depending on the
project with the CommandViewManager class though.

I checked Window/Debugging/Sources and the sources listed are correct.

I'm running Netbeans on Linux

Created attachment 51606 [details]
log file after occurence, with -D-J option on

Created attachment 51607 [details]
screenshot of invalid breakpoint in editor

Created attachment 51608 [details]
screenshot of invalid breakpoint in editor

Where I am seeing this is when I debug a remote copy of Tomcat, then make a change, rebuild the war file, and redeploy.
 Even if I stop and restart the debugger, he doesn't seem to recognize breakpoints in changed code unless I restart Tomcat.
 

Created attachment 51676 [details]
another UI Gestures dump with the -J-D option on

Created attachment 51679 [details]
screen dump corresponding to previous UI Gestures attachment

Created attachment 51682 [details]
messages.log

Created attachment 54726 [details]
invalid breakpoint - stopped anyway, incorrect highlight

This does not look like a bug in debugger itself. There are not availabe the appropriate line locations in the bytecode.
Thus maybe a compiler issue? Can you attach some source file that would demonstrate this behavior?
It's very strange that it works a while and stops working later on. The association with Java cache is also strange. It
looks like a bug outside of debugger scope. Some testcase would allow us to find the root cause of the problem. Thanks.

I'm seeing this in my log, is it related?  I only seem to experience this issue when debugging a remote app server.

INFO [org.netbeans.modules.j2ee.deployment.impl.ServerInstance]: DebuggerInfo cannot be found for: GlassFish V2 (external)
INFO [org.netbeans.modules.j2ee.deployment.impl.ServerInstance]: DebuggerInfo cannot be found for: GlassFish V2 (external)
INFO [org.netbeans.modules.j2ee.deployment.impl.ServerInstance]: DebuggerInfo cannot be found for: Tomcat 6.0 (external)
INFO [org.netbeans.modules.j2ee.deployment.impl.ServerInstance]: DebuggerInfo cannot be found for: GlassFish V2 (external)

I have the same problem when compiling the class and running socket attach debugger : 

Not able to submit breakpoint LineBreakpoint Graficador.java : 53, reason: Line number information is missing in the
class file com.pruebas.Graficador.

The server is an Oracle IAS Application Server.

Other thing is the button "apply code changes", the butto is always deactivated and i don't known how to activate

esorribas, when line number information is missing in your classes, you will not be able to submit breakpoints. You need
to compile the classes with -g to enable debugging.

I do not think that the message about DebuggerInfo has any effect here, I also see these messages.
Moving to J2EE debugger for evaluation, since this issue occurs when debugging a remote app server.

This is my ide-file-targets.xml configuration:

    <target name="compile-selected-files-in-java">
        <fail unless="files">Must set property 'files'</fail>
        <!-- TODO decide on and define some value for ${build.classes.dir} -->
        <mkdir dir="hphis-war/web/WEB-INF/classes"/>
        <javac destdir="hphis-war/web/WEB-INF/classes" includes="${files}" source="1.4" srcdir="hphis-war/src/java">
            <compilerarg value="-g"/>
            <classpath
path="C:\cvs_trabajo\lib\activation.jar;C:\cvs_trabajo\lib\ant-contrib.jar;C:\cvs_trabajo\lib\ant-launcher.jar;C:\cvs_trabajo\lib\ant.jar;C:\cvs_trabajo\lib\antlr-2.7.6rc1.jar;C:\cvs_trabajo\lib\asm-attrs.jar;C:\cvs_trabajo\lib\asm.jar;C:\cvs_trabajo\lib\avalon-framework-4.1.5.jar;C:\cvs_trabajo\lib\avalon.jar;C:\cvs_trabajo\lib\axis-ant.jar;C:\cvs_trabajo\lib\axis-schema.jar;C:\cvs_trabajo\lib\axis-wsdl4j-1.2.jar;C:\cvs_trabajo\lib\axis.jar;C:\cvs_trabajo\lib\axis2-0.9.jar;C:\cvs_trabajo\lib\b64enc.jar;C:\cvs_trabajo\lib\barcode4j-demo-applet.jar;C:\cvs_trabajo\lib\barcode4j-light.jar;C:\cvs_trabajo\lib\batik.jar;C:\cvs_trabajo\lib\bonita-client.jar;C:\cvs_trabajo\lib\bsh-1.3.0.jar;C:\cvs_trabajo\lib\bsh-2.0b4.jar;C:\cvs_trabajo\lib\c3p0-0.9.0.jar;C:\cvs_trabajo\lib\cglib-2.1.3.jar;C:\cvs_trabajo\lib\cleanimports.jar;C:\cvs_trabajo\lib\comm.jar;C:\cvs_trabajo\lib\common-softvaluehashmap.jar;C:\cvs_trabajo\lib\commons-beanutils-bean-collections.jar;C:\cvs_trabajo\lib\commons-beanutils-core.jar;C:\cvs_trabajo\lib\commons-cli-1.0.jar;C:\cvs_trabajo\lib\commons-collections-3.1.jar;C:\cvs_trabajo\lib\commons-dbcp-1.2.1.jar;C:\cvs_trabajo\lib\commons-digester-1.7.jar;C:\cvs_trabajo\lib\commons-discovery-0.2.jar;C:\cvs_trabajo\lib\commons-discovery.jar;C:\cvs_trabajo\lib\commons-el.jar;C:\cvs_trabajo\lib\commons-javaflow-r306555.jar;C:\cvs_trabajo\lib\commons-lang-2.3.jar;C:\cvs_trabajo\lib\commons-logging-1.0.4.jar;C:\cvs_trabajo\lib\commons-logging-api.jar;C:\cvs_trabajo\lib\commons-logging.jar;C:\cvs_trabajo\lib\commons-net-1.4.1.jar;C:\cvs_trabajo\lib\commons-pool-1.2.jar;C:\cvs_trabajo\lib\concurrent.jar;C:\cvs_trabajo\lib\derby.jar;C:\cvs_trabajo\lib\DocAnotacion20.jar;C:\cvs_trabajo\lib\dom4j-1.6.1.jar;C:\cvs_trabajo\lib\ehcache-1.1.jar;C:\cvs_trabajo\lib\ejb.jar;C:\cvs_trabajo\lib\fop.jar;C:\cvs_trabajo\lib\gnu-regexp.jar;C:\cvs_trabajo\lib\gsbase-2.0.1.jar;C:\cvs_trabajo\lib\hapi_0.3.jar;C:\cvs_trabajo\lib\hcis-ant.jar;C:\cvs_trabajo\lib\hibernate3.jar;C:\cvs_trabajo\lib\ibatis-common-2.jar;C:\cvs_trabajo\lib\ibatis-sqlmap-2.jar;C:\cvs_trabajo\lib\ifxjdbc.jar;C:\cvs_trabajo\lib\imageLibrary.jar;C:\cvs_trabajo\lib\instantj-1.6.jar;C:\cvs_trabajo\lib\itext-1.3.1.jar;C:\cvs_trabajo\lib\j2ee.jar;C:\cvs_trabajo\lib\jasper-compiler.jar;C:\cvs_trabajo\lib\jasper-runtime.jar;C:\cvs_trabajo\lib\jasperreports-1.2.2.jar;C:\cvs_trabajo\lib\javassist.jar;C:\cvs_trabajo\lib\jaxen-core-1.0-fcs.jar;C:\cvs_trabajo\lib\jaxme2-0.5.jar;C:\cvs_trabajo\lib\jaxrpc-api.jar;C:\cvs_trabajo\lib\jaxrpc-impl.jar;C:\cvs_trabajo\lib\jaxrpc.jar;C:\cvs_trabajo\lib\jazzy-core.jar;C:\cvs_trabajo\lib\jboss-aop.jar;C:\cvs_trabajo\lib\jboss-aspect-library.jar;C:\cvs_trabajo\lib\jboss-aspect-library32.jar;C:\cvs_trabajo\lib\jboss-cache.jar;C:\cvs_trabajo\lib\jboss-common.jar;C:\cvs_trabajo\lib\jboss-j2ee.jar;C:\cvs_trabajo\lib\jboss-jmx.jar;C:\cvs_trabajo\lib\jboss-serialization.jar;C:\cvs_trabajo\lib\jboss-system.jar;C:\cvs_trabajo\lib\jbosssx.jar;C:\cvs_trabajo\lib\jcom.jar;C:\cvs_trabajo\lib\jcommon-0.7.1.jar;C:\cvs_trabajo\lib\jcommon-1.0.12.jar;C:\cvs_trabajo\lib\JCSC.jar;C:\cvs_trabajo\lib\jdbm-1.0.jar;C:\cvs_trabajo\lib\jdk14-pluggable-instrumentor.jar;C:\cvs_trabajo\lib\jdom.jar;C:\cvs_trabajo\lib\jep-2.24.jar;C:\cvs_trabajo\lib\jfreechart-0.9.4.jar;C:\cvs_trabajo\lib\jfreechart-1.0.8.jar;C:\cvs_trabajo\lib\jgroups.jar;C:\cvs_trabajo\lib\jmyspell.1.0_7.jar;C:\cvs_trabajo\lib\jRegistryKey.jar;C:\cvs_trabajo\lib\jrockit-pluggable-instrumentor.jar;C:\cvs_trabajo\lib\js.jar;C:\cvs_trabajo\lib\jsp-api.jar;C:\cvs_trabajo\lib\jstl.jar;C:\cvs_trabajo\lib\jta.jar;C:\cvs_trabajo\lib\jTidy.jar;C:\cvs_trabajo\lib\juh.jar;C:\cvs_trabajo\lib\junit-3.8.1.jar;C:\cvs_trabajo\lib\junit.jar;C:\cvs_trabajo\lib\junitperf-1.8.jar;C:\cvs_trabajo\lib\jurt.jar;C:\cvs_trabajo\lib\jut.jar;C:\cvs_trabajo\lib\jxl.jar;C:\cvs_trabajo\lib\log4j-1.2.14.jar;C:\cvs_trabajo\lib\log4j-1.2.8.jar;C:\cvs_trabajo\lib\logOrionLib.jar;C:\cvs_trabajo\lib\lucene-1.4.3.jar;C:\cvs_trabajo\lib\mail.jar;C:\cvs_trabajo\lib\naming-common.jar;C:\cvs_trabajo\lib\naming-factory.jar;C:\cvs_trabajo\lib\naming-java.jar;C:\cvs_trabajo\lib\naming-resources.jar;C:\cvs_trabajo\lib\ognl-2.6.9.jar;C:\cvs_trabajo\lib\ojdbc14.jar;C:\cvs_trabajo\lib\org.jar;C:\cvs_trabajo\lib\oscache-2.1.jar;C:\cvs_trabajo\lib\pmd-3.2.jar;C:\cvs_trabajo\lib\poi-2.5.1-final-20040804.jar;C:\cvs_trabajo\lib\proxool-0.8.3.jar;C:\cvs_trabajo\lib\qdox.jar;C:\cvs_trabajo\lib\rhapsody.jar;C:\cvs_trabajo\lib\ridl.jar;C:\cvs_trabajo\lib\saaj.jar;C:\cvs_trabajo\lib\saxpath-1.0-fcs.jar;C:\cvs_trabajo\lib\servlet-2.2.jar;C:\cvs_trabajo\lib\servlet-api.jar;C:\cvs_trabajo\lib\servlet.jar;C:\cvs_trabajo\lib\SOAP_SCF.jar;C:\cvs_trabajo\lib\spring-binding-1.0-rc2.jar;C:\cvs_trabajo\lib\spring-web.jar;C:\cvs_trabajo\lib\spring-webflow-1.0-rc2.jar;C:\cvs_trabajo\lib\spring-webmvc.jar;C:\cvs_trabajo\lib\spring.jar;C:\cvs_trabajo\lib\standard.jar;C:\cvs_trabajo\lib\stax-1.1.1-dev.jar;C:\cvs_trabajo\lib\stax-api-1.0.jar;C:\cvs_trabajo\lib\swarmcache-1.0rc2.jar;C:\cvs_trabajo\lib\template.jar;C:\cvs_trabajo\lib\tools.jar;C:\cvs_trabajo\lib\trove.jar;C:\cvs_trabajo\lib\unoil.jar;C:\cvs_trabajo\lib\urlrewrite-2.6.0.jar;C:\cvs_trabajo\lib\velocity-dep.jar;C:\cvs_trabajo\lib\weblogic.jar;C:\cvs_trabajo\lib\wsdl4j-1.5.1.jar;C:\cvs_trabajo\lib\wsdl4j.jar;C:\cvs_trabajo\lib\xalan-2.5.2.jar;C:\cvs_trabajo\lib\xalan.jar;C:\cvs_trabajo\lib\xbean-2.0.0-beta1.jar;C:\cvs_trabajo\lib\xercesImpl.jar;C:\cvs_trabajo\lib\xml-apis.jar"/>
        </javac>
    </target>


And the "apply code changes" button is deactivated most the time

Still seeing this with build 200809300201 of NetBeans 6.5.  I've attached a screenshot that was taken after a clean and
build, then a deploy (to an external copy of GlassFish).  Not an executable location, but then breakpoint successfully
submitted, then not an executable location, but then breakpoint hit anyway.  What is going on here?

Created attachment 70928 [details]
screenshot: first it isn't, then it is, then it isn't, then it is...

I believe that we have enough information now. Hence removing INCOMPLETE keyword. Any update on this? Please note that
this issue was selected by Glenn Holmer (reputable NetCAT participant) as a potential 6.5 FCS showstopper [1].

[1] http://www.nabble.com/-65cat---other--Early-CA-research-tc19665753.html

Glen, how many classes com.weycogroup.phoenix.storefront.CategoryBean do you have?
It looks like there are three of them loaded according to the screenshot. In the first one there was no location defined
for line 239, in the second there was, thus the breakpoint was successfully submitted. And in the third, again, no such
location was found.

Does this imply any functional problems?

Can you please provide some sample project that would demonstrate this behavior? I have never had a problem of this kind.

A sample project and steps to reproduce would be the best. But if you can not provide it, please use
-J-Dorg.netbeans.modules.debugger.jpda.level=400 option as described above and attach the message.log generated after
the described situation occurs. This can, at least, provide some hint of what's going on there. Thanks.

> Glen, how many classes com.weycogroup.phoenix.storefront.CategoryBean do you have?
Exactly one.

> please use -J-Dorg.netbeans.modules.debugger.jpda.level=400
I have turned this on again.

I'm adding another log file and screen dump.
I was debugging an enterprise app using an external copy of GlassFish (using "Attach Debugger).
I detached the debugger, made a change, did a clean and build, then a deploy.
When I started the debugger again, I saw what's in the screen dump.
I have done a "Clone Document" on CategoryBean.java after it occurred but before taking the screen dump, so you can see
both lines at the same time.
There is only one of these files in the project.

Created attachment 71059 [details]
log file

Created attachment 71060 [details]
screen dump

Aha, I see what's going on now. There are several copies of each class loaded by different class loader.
The GlassFish apparently contains all classes that were ever deployed. Therefore when breakpoints are submitted, they
are naturally trying to be submitted into all these copies. And when line number changes, it can easily happen that some
locations in some copies becomes invalid (there is no executable code). This is why you get notification that the
breakpoint is invalid and subsequently it's successfully submitted into a different copy of the same class.

IMHO this is a defect of the GlassFish, since you probably do not care about the old copies, which only take up space.
But I might be wrong. If it is desired to have multiple different copies loaded, I will try to find some solution how to
silently ignore the invalid messages.

I'm using Tomcat with the same problems. If it's a Glassfish problem then Tomcat is using the same class loading
mechanism. Possible.

This bug is considered as potential showstopper [1] by NetCAT 6.5 participant. Adding [65cat] prefix.

[1] http://www.nabble.com/-65cat---other--Early-CA-research-tp19665753p19748154.html

Easily reproducible even with the latest glassfish-v3-prelude-b27.
The classes are cumulating on the server. I'll submit a defect for that.

However, the breakpoint validity becomes useless here, since we can not know which version of the class is going to be
actually used. Therefore you could have "valid" breakpoints for empty lines which are, by chance, valid in some old copy
of the class.

I do not see a clean solution to this. It will, most likely, NOT be fixed into 6.5, sorry.

I've submitted https://glassfish.dev.java.net/issues/show_bug.cgi?id=6416

I can only think of some maybe GlassFish-specific (and perhaps Tomcat-specific) fix if we'll be able to find out which
class loader is the newest one (which will be actually used).

The GlassFish issue was just fixed, could someone please try to verify with the latest nightly build of v3 Prelude?
Cc'ing Peter W and Vince. Martin, thanks a lot for the investigation!

*** Issue 148315 has been marked as a duplicate of this issue. ***

I have a terrible time with this with the current version NetBeans 6.5 and glassfish-v2ur2, all updated to the latest
level. Invalid breakpoints. Now I don't know how to get the debugger to work at all.
Somehow sources from the favorites window were automatically added to the debugger sources window. Is this allowed to
happen? I wrote a program to search my drives for all duplicate classes including within jar files on my harddrive.
Deleted all, including from the netbeans cache. Re-started NetBeans multiple times. Cleaned, closed, re-opened the
project. Now the debugger does not stop on breakpoints anymore. It appears to me that there are multiple issues that are
quite toxic in combination. I have had another more obvious problem with NetBeans/glassfish when trying to re-build
projects even when they are undeployed from the server:
nbproject\build-impl.xml:398: Unable to delete file dist\gfdeploy\Member-war_war\WEB-INF\lib\wicket-extensions-1.3.5.jar
There are multiple issues and symptoms. Therefore I think that this should have a high priority.

Debugger worked again after I re-added the source root to the sources window. A couple of source code changes, deployed,
and all breakpoints are broken again.

I think it would be good to add a function to add the project's source root if a breakpoint is set on a project file
whose source root is not included in the sources window. But that does not solve the problem, it just demonstrates who
many issues exist in this field.

Nothing from Favourites window is added to debugger sources. Only current project and all it's dependent projects.

There is no known mechanism how a project's source root is "automatically" removed from the Sources window.

Was not the problem with not working breakpoints caused by your delete of all classes and JAR files?

GlassFish keeps multiple classes loaded for the same source code. Unless they have already fixed this (I'll check it)
this is causing breakpoints to be falsely marked as invalid. Though they should still work fine.

Please note that the GF side of this is marked as fixed for GF v3 and GF v2.1...

Are you running into this problem when you use GF v2.1 instead of GF v2 ur 2?

More info about v2.1 is available from http://wiki.glassfish.java.net/Wiki.jsp?page=PlanForGlassFishV2.1

Has this been verified for Glassfish 2.1/V3 ? Can this issue be closed ?

This issue still exist for tomcat

From the discussions so far, it doesn't look like j2ee issue. If the fix to Glassfish fixed your problem, then it must
be a bug in the server side, you would have to file an issue against Tomcat and get the issue addressed. 
Martin, do you see anything that we can do to fix this ? 
thanks

Sorry not to have responded, we've been doing a lot of R&D and very little debugging.

But one of the guys on my team got this same bug today (see attachment).  He's running build b56 of GlassFish 2.1.

Created attachment 75837 [details]
screenshot

thanks for the update.

See attached screenshot. All the messages about line 40 came from a single remote debugger attach. Using GlassFish 2.1 GA.

Created attachment 76194 [details]
screenshot

after reading through the comments in this issue it appears that many servers have a similar 'bug'.

So, we may want to examine how the debugger works against the current environment while we wait for various servers to
address the issues that we have raised.

Also, from the description it sounds like the workaround should be to restart the server, and avoid running multiple
applications that use the same classes. Does this workaround help?

Yes, restarting helps with Tomcat. That's how I work around it.

I'm now investigating if the problem arises when deploying with and without the debugger attached. It also seems to have
some effect.

I assume the same workaround also applies to GlassFish - changing priority to P2 for now.

Martin E, if we are not able to fix this issue properly (though we will keep trying), do you think it would be possible
to change the error message to include the hint that server restart will help? Thanks.

Naturally, restarting the server helps... but imagine the impact of that while working on a large application.  I just
ignore the error messages because I know the debugger will break on those lines anyway... but it's very untidy.

Looks like this issue will be hard to fix, especially since for NB 6.7, we will use GF v2.1, so any fix in v3 will not
help. I suggest to waive this bug for 6.7.

Waived for NB 6.7.

I'll try to resolve this somehow into 6.8.
The fact that the server holds several class types for the same class name may cause also other problems to NetBeans
debugger. For instance issue #163249 was caused by this.

In general, it's impossible to provide correct breakpoint badging when the application loads several classes with
identical names and when line numbers of these classes differ. I can easily write an application, that will load several
classes of one name with shifted line numbers and execute randomly different classes.
Then breakpoint submitted to particular line will randomly either work or not, depending on whether it happens to be on
an executable line in the given class or not. One breakpoint can be valid in some classes, while invalid in others.

It's also possible (and this happens with the Glassfish server), that initially, when debugger is being connected, all
classes of the given name that are loaded in the VM are already outdated, have old line numbers and thus breakpoints in
these classes are marked as invalid (suppose that line numbers point to empty lines in these old classes).
But then a new, updated, class is loaded into the VM with up-do-date line numbers. Then the breakpoint is marked  as
valid. But the error messages about invalid breakpoints remain in the Output window.
Such breakpoint is valid only in the newest class, not in others. Glassfish seems to use the newest class only, but not
all applications have to behave that way.

Should be fixed in changeset:   135792:0cd5a8599734
We try to recognize staled classloaders and submit breakpoints only to the classes that are loaded by active class loaders.
http://hg.netbeans.org/main/rev/0cd5a8599734

Integrated into 'main-golden', will be available in build *200906230201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/0cd5a8599734
User: mentlicher@netbeans.org
Log: #115033 - When more classes of the same name are loaded in the system when a breakpoint is to be submitted, select the preferred class and mark the breakpoint validity based on the preferred class. This works fine for glassfish server, whose staled class loaders have null parent. Inform also about partially submitted breakpoints.

Any chance of this going into 6.7, even as a hotfix?

Glenn, can you please confirm that it works fine for you in the #200906230201 development build? Thanks!

In case it helps and if it's verified, I guess it can be added into the 67 patch.

I'm sorry to say, attaching the debugger to a running copy of GlassFish with build 20090623 locks up the IDE and is
repeatable.  See attached log file and thread dump.

Created attachment 83934 [details]
thread dump

Created attachment 83935 [details]
log file from userdir

This deadlock does not seem to be caused by this fix. It's already submitted in issue #167444 and was fixed just today.
So please try the next build, it will hopefully work fine.

I've been working with 200906240201 all morning, doing intensive remote debugging with GlassFish, and have not seen a
single invalid breakpoint badge.  As far as I can see, the debugger is always stopping where it should.

From my perspective, this is fixed.  I would love to see it go into 6.7.

v.

The fix has been ported into the release67_fixes repository.
http://hg.netbeans.org/release67_fixes/rev/65fb554b7a48

The last comment reads that this is fixed in 6.7. But I see the same bug in 6.7 on a daily basis. My results are
actually worse. After a complete clean, deploy and debug sequence, the debugger stops on some breakpoints but not on others.

I read on https://glassfish.dev.java.net/issues/show_bug.cgi?id=6416 that the issue still persists.

So how can this be closed then?

I am extremely frustrated, and I would not be surprised if the hard working people at Sun, and in the NetBeans team are
frustrated, too.

So my thinking is now that we, the users need to help the Sun server developers and the NetBeans developers to escalate
this, to put it in perspective, in order not to lose users due to frustration.

If for example, I was a development team leader or development manager, then I would not even dream of recommending
NetBeans as a viable development environment for J2EE development. The first developer would shoot me down. I personally
like NetBeans and I use it, and I have not given up yet, but I think I am losing.

Well, it is the server not NetBeans you may say, and possibly rightly so. But the server comes with NetBeans out of the
box, and we would expect it to be the best choice.

There are other persisting and very frustrating issues with NetBeans: 

issue 145666 "Source root's non-class files not included on Auto deploy" and  issue 152222 "Unnecessary redeploys by
'deploy on save'". This is a toxic mix and I ask myself what is going on here, who can use NetBeans to develop server
software? It is very sad to see that while there are so many brilliant features in this software, the daily work with
NetBeans can be so utterly unproductive and frustrating.

Bernard, actually, release67_fixes is different from "NetBeans 6.7". The previous comment means that this fix will be
available in Patch 1 for NetBeans 6.7 (also known as 6.7.1). So it is not fixed in 6.7. Patch 1 will be available by the
end of July. If you want to test it now, you can also use the NetBeans 6.8 daily builds:
http://bits.netbeans.org/netbeans/trunk/nightly/

Changing back to FIXED.

... and VERIFIED.

Please note, that the "Target milestone" here is still "6.8". Therefore this issue is *not* fixed in 6.7.

The fix has been integrated into patch1 for 6.7, which is not publicly available yet, AFAIK.

Let's wait how it will work for you after you install the patch with this fix.

v.

verified in 6.7.1 RC
NetBeans IDE 6.7.1 RC (Build 200907162301)

The fix will be available next week as 6.7.1 and also in patch for 6.7

*** Issue 168380 has been marked as a duplicate of this issue. ***