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.
1) Create breakpoint in some NB module (e.g. openide.explorer) 2) Debug IDECommitValidationTest -> breakpoint is ignored
ide.kit does not have openide.explorer on it's class-path. Therefore breakpoints in openide.explorer are ignored. I'm further investigating where is the class-path set. As a simple fix, enable openide.explorer/src in Sources window.
I do not see a way how to fix this, therefore this likely ends up as will-not-fix. NetBeans uses some class-path for it's start. But later, it loads dynamically further modules and extends it's "class-path". But this can not be detected. Even when I ask for System.getProperty("java.class.path") after the breakpoint in explorer is hit, I do not get the openide.explorer in it. You need to customize the source-path manually (in Sources window) when your application does this sort of things.
I will further think about adding all other source paths from other opened projects at the end of the current source path. That would fix this problem. We need to be careful not to break any other use-cases.
The ideal solution would be to notice the getProtectionDomain0().codesource.location of the newly loaded class as the app runs and associate the right source tree with it. Not sure if this can be done efficiently, but it would be precise and automatic.
For local sessions we can use the getProtectionDomain0().codesource.location approach to find the class location. But this has two major problems - it's Sun's JDK specific, since it relies on private API and it requires to invoke methods (method invocations do not work at all on J2ME). Therefore we still have to have some other solution that would work if this method fails. Then there's a question if we should pollute the code with such proprietary solution if we have to have other working mechanisms when this fails. If JDI would provide the code source location, all would be much easier. IMHO we can solve this by submitting BP requests for all classes that belong to the debugging project (including dependent project), plus all breakpoints which are located in all other source roots, but their class is *not* in project's sources. That way breakpoints in different copies of classes should work in the debugged project only (as they do now) while breakpoints in unrelated classes would be subject of submission if such class happens to be loaded.
Since this concerns mostly NetBeans developers, downgrading to P3 - not a problem for most of our users. I'll try to solve into 6.7 FCS though.
P3 sounds fine. May affect people using other kinds of container-based applications - e.g. OSGi apps, ClassWorlds, Jetty + web app, etc. etc. But probably not the common case. You could check if 'private native java.security.ProtectionDomain getProtectionDomain0()' exists in java.lang.Class - should be true of any non-ME Sun JVM, which is to say the great majority of what our users will be running (and this kind of issue would likely never occur for Java ME anyway). The public Class.getProtectionDomain() could perhaps be used too, it just runs a bit more code which might trigger SecurityException's etc. "...we can solve this by..." - not completely sure I followed the proposal, but if it works, then great.
IDECommitValidationTest is gone. Debug on any test says: "Class "null" does not have a main method." Really nice! Debug on "ide.kit" module now collects *full* class-path. Therefore all modules are enabled for debugging and breakpoints on all of them should work fine. Therefore there does not seem to be anything to fix for debugging of NetBeans!? I've made the fix already, but it looks like I'm not able to verify it on NetBeans. The fix might be good for applications that add additional items to class-path (which does not seem to be the case of NetBeans any more, probably only when user will install a module from autoupdate, which is an extremely rare case IMHO). Tomasi, do you still have this problem with breakpoints while debugging NetBeans? If not, I reconsider the fix, if it's safe enough to be applied just for hypothetical cases. I'll test on some sample application...
Hopefully this fix does not break anything. Now we consider almost all breakpoints for submission into the debugging application. Fixed in changeset: 129374:5aed99f3eaf0 http://hg.netbeans.org/main/rev/5aed99f3eaf0
IDECommitValidationTest is now in java.kit. The problem still existed in NetBeans IDE Dev (Build 090428). If you want to debug test you have to select Debug->Debug Test File.
Integrated into 'main-golden', will be available in build *200904300201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/5aed99f3eaf0 User: mentlicher@netbeans.org Log: #152425 - Submit requests for all breakpoints that exist in the system. We ignore only breakpoints in classes not being on the classpath, but classes of that name exist in project's classpath. This makes breakpoints in dynamically loaded classes (not from project's classpath) to work.
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.