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.
Product Version: NetBeans IDE 6.7.1 (Build 200907230233) Java: 1.6.0_06; Java HotSpot(TM) Client VM 10.0-b22 System: Windows 2000 version 5.0 running on x86; Cp1252; en_NZ (nb) Userdir: C:\Documents and Settings\Administrator\.netbeans\6.7 In this example, source code parsing inside a single library breaks. On the surface, it appears that the parser gets confused because it ascends the directory tree interpreted as package hierarchy beyond the mount point. How to reproduce: - Start NetBeans fresh with an empty profile - Install the Wicket plugin - Menu|File|New Project|Java Web|Web Application - Application server: GlassFish V2 - Java EE 5 - Framework: Wicket 1.4 This project includes a library "Wicket". We might to want update the library with later versions, or we might want to add additional packages. To keep things simple, we replace the source code of the library with the copy of the distribution with the matching version. - Download the matching Wicket archive (1.4.0 in my case) and extract it to a directory - Menu|Tools|Libraries|Wicket|Tab Sources - Remove the single Sources entry - Click "Add JAR/Folder" - Select the directory src\wicket\src\main\java in your extracted distribution and click OK - Menu|Navigate|Go to Type| (or [Ctrl+O]), type DropDownChoice, click OK The file is opened but there are 21 parsing errors. The interesting part is that the parsing errors relate to packages and sources that are included in the directory. The errors are all bogus. - Close the Java file - Remove the Wicket library from your project - Remove the source directory from the Wicket library - Delete all directories beside the directory src\wicket\src\main\java in your extracted distribution Now there is only a single source root in the crippled extracted distribution. A diff operation finds that except a couple of files e.g. manifest, all files are identical. - Add the directory src\wicket\src\main\java of your extracted distribution to the Wicket library - Add the Wicket library to your project - Menu|Navigate|Go to Type| (or [Ctrl+O]), type DropDownChoice, click OK You may find that this fixes the problem. I am not claiming that I know exactly what is going on. But it looks like NetBeans was confused by the other source roots in the distribution that it should NOT be allowed to access. This is only my best shot at a problem that I have seen many times before, and it is a BIG problem.
I haven't been able to reproduce this issue. Could you please help us to figure the real cause out. Please do following: 1. start the IDE with switches: "-J-ea" and "-J-Dorg.netbeans.api.java.queries.SourceLevelQuery.level=0" 2. try to reproduce the issue, some pictures of errors in the IDE could help either 3. attach "messages.log" (located in <nb_user_dir>/var/log) 4. attach "Boot Classpath" - in "Navigator" window -> "Classpath (NetBeans Development) combo box" Thanks.
Created attachment 86782 [details] messages.log
Thanks fr your help. I could not re-start the test case because when I renamed ,y .netbeans dir, then I could not find a way to activate the feature for a web project - not listed. So I tried with my current .netbeans dir. The command line is: "C:\Program Files\NetBeans 6.7.1\bin\netbeans.exe" -J-ea -J-Dorg.netbeans.api.java.queries.SourceLevelQuery.level=0 Where can I find "Boot Classpath"? I realised that in order to be consistent, the test case should include instructions to also replace the wicket-1.4.0.jar in the library Wicket with the file from the wicket distribution. When I did that then DropDownChoice was not found at all. So I made a mistake in the test case but it should not matter, because in fact the files wicket-1.4.0.jar are the same in the wicket plugin as in the wicket distribution. I hope that the log file is helpful. In the meantime I don't know which way to go to make progress.
Thanks for the info. "Boot Classpath" - select java file of your project in "Projects" view. Then switch to "Navigator" window (it should be placed under "Projects" view). In the top of it you can expand component and there should "Classpath (NetBeans Development)" -> Boot Classpath. Press "..." button underneath and you should be able to view its content.
Thanks for the tip. "Boot Classpath" C:\Program Files\Java\jdk1.6.0_06\jre\lib\resources.jar;C:\Program Files\Java\jdk1.6.0_06\jre\lib\rt.jar;C:\Program Files\Java\jdk1.6.0_06\jre\lib\sunrsasign.jar;C:\Program Files\Java\jdk1.6.0_06\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.6.0_06\jre\lib\jce.jar;C:\Program Files\Java\jdk1.6.0_06\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.6.0_06\jre\classes;C:\Program Files\Java\jdk1.6.0_06\jre\lib\ext\dnsns.jar;C:\Program Files\Java\jdk1.6.0_06\jre\lib\ext\localedata.jar;C:\Program Files\Java\jdk1.6.0_06\jre\lib\ext\sunjce_provider.jar;C:\Program Files\Java\jdk1.6.0_06\jre\lib\ext\sunmscapi.jar;C:\Program Files\Java\jdk1.6.0_06\jre\lib\ext\sunpkcs11.jar
Created attachment 86804 [details] Parsing in editor broken with source code jar file from wicket distribution not plugin.
Created attachment 86805 [details] Go to Type broken with lib jar file from wicket distribution not plugin.
Note for screen shots: In GoToTyppeBroken.gif you see at the left in Projects window the expanded "Libraries Wicket - wicket-1.4.0.jar". The org.apache.wicket.markup.html.form.DropDownChoice is clearly visible, and the project compiles ok. I feel frustrated and sorry that I cannot help you more. May be this is related to maven after all. I encountered this problem before, with a previous version of NetBeans only after I installed the maven plugin, issue 156597 . I got rid of it and that solved the problem. All I can see now is that there is a mercurial error in the log. On the other hand with the high quality of NetBeans we would not expect this type of thing to be easy to find :)
Required info provided.
Could you please also add the content of compile classpath? (Or, maybe, all classpaths listed in the navigator, source, compile, boot and runtime, in both translated and not-translated variants.) Thanks.
I am failing to access properties from the Navigator window. How can I do this? I think you want the source classpath but I can't find it. I don't know what you mean by "Classpath (NetBeans Development)" in your previous comment. I opened the properties from the project window instead. Please refer to new screen shot. Projects window, properties of Application.java Compile Classpath C:\Documents and Settings\Administrator\.netbeans\6.7\libs\wicket-1.4.0.jar;C:\Documents and Settings\Administrator\.netbeans\6.7\libs\slf4j-api-1.4.2.jar;C:\Documents and Settings\Administrator\.netbeans\6.7\libs\slf4j-jdk14-1.4.2.jar;C:\Sun\AppServer\lib\endorsed\webservices-api.jar;C:\Sun\AppServer\lib\javaee.jar;C:\Sun\AppServer\lib\jsf-impl.jar;C:\Sun\AppServer\lib\activation.jar;C:\Sun\AppServer\lib\appserv-tags.jar;C:\Sun\AppServer\lib\mail.jar;C:\Sun\AppServer\lib\appserv-jstl.jar;C:\Sun\AppServer\lib\webservices-tools.jar;C:\Sun\AppServer\lib\webservices-rt.jar;C:\Sun\AppServer\lib\webservices-tools.jar;C:\Sun\AppServer\lib\webservices-rt.jar;C:\Sun\AppServer\lib\appserv-ws.jar Runtime Classpath C:\bt\java\netbeans\bugs\_new\WickeSourceBroken\Test\build\web\WEB-INF\classes;C:\Documents and Settings\Administrator\.netbeans\6.7\libs\wicket-1.4.0.jar;C:\Documents and Settings\Administrator\.netbeans\6.7\libs\slf4j-api-1.4.2.jar;C:\Documents and Settings\Administrator\.netbeans\6.7\libs\slf4j-jdk14-1.4.2.jar;C:\Sun\AppServer\lib\endorsed\webservices-api.jar;C:\Sun\AppServer\lib\javaee.jar;C:\Sun\AppServer\lib\jsf-impl.jar;C:\Sun\AppServer\lib\activation.jar;C:\Sun\AppServer\lib\appserv-tags.jar;C:\Sun\AppServer\lib\mail.jar;C:\Sun\AppServer\lib\appserv-jstl.jar;C:\Sun\AppServer\lib\webservices-tools.jar;C:\Sun\AppServer\lib\webservices-rt.jar;C:\Sun\AppServer\lib\webservices-tools.jar;C:\Sun\AppServer\lib\webservices-rt.jar;C:\Sun\AppServer\lib\appserv-ws.jar Boot Classpath C:\Program Files\Java\jdk1.6.0_13\jre\lib\resources.jar;C:\Program Files\Java\jdk1.6.0_13\jre\lib\rt.jar;C:\Program Files\Java\jdk1.6.0_13\jre\lib\sunrsasign.jar;C:\Program Files\Java\jdk1.6.0_13\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.6.0_13\jre\lib\jce.jar;C:\Program Files\Java\jdk1.6.0_13\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.6.0_13\jre\classes;C:\Program Files\Java\jdk1.6.0_13\jre\lib\ext\dnsns.jar;C:\Program Files\Java\jdk1.6.0_13\jre\lib\ext\localedata.jar;C:\Program Files\Java\jdk1.6.0_13\jre\lib\ext\sunjce_provider.jar;C:\Program Files\Java\jdk1.6.0_13\jre\lib\ext\sunmscapi.jar;C:\Program Files\Java\jdk1.6.0_13\jre\lib\ext\sunpkcs11.jar In the meantime I had completely uninstalled and re-installed NetBeans but the problem persists. My workaround is to put the wicket sources into zip files and reference those.
Created attachment 88149 [details] Screen shot of project/navigator window
Created attachment 88150 [details] Screen shot of project/navigator window
This is 6.7.1 ... can the reporter check the situation in the dev build or 6.8 M2? The classpath in the dev build should be visible ...
Fantastic. I cannot reproduce this with 6.8M2. At the same time I can still reproduce it with 6.7 on the same computer, so I am quite confident the problem is solved. Many thanks. I am closing as resolved fixed.
verified by reporter thanks
Created attachment 91715 [details] Log files in zip file NetBeans IDE 6.8 Beta (Build 200910212001) It happens again, now with files of my own project. So far it reproduces all the time - in fact I don't know how to get out of this, but I have used the beta for quite a while without any occurrence of this. Hope the log file helps to pinpoint the bug.
Comment on attachment 91715 [details] Log files in zip file Error
Sorry, this was an error.
NP. Marking again as "verified" then...
Initially reported in 6.7, then thought it was gone in 6.8, but back again in 6.8. My guess is that NetBeans gets confused, and this is not Wicket related. I have seen this with other libraries recently, and again it appears to happen only if there are both standard AND Maven projects involved. With that I mean that Maven projects do not necessarily need to be open, just that Maven was used before, just enough to get NetBeans confused. I blame Maven a bit because I did not have this problem for months until I started using Maven a little. In fact I hate Maven because it tends to screw things up for me. Component.java and source code of some of the red packages classes are in the same library resource i.e. wicket/src/main/java of the downloaded wicket sources, which are in a Maven project that I have never used. In my Wicket library I just use this directory as source directory. I can open any of the red classes with "Goto Type", and the dialog lists only one source code location. [Ctrl+click] or [Ctrl+B] on the same does not work. Can we approach this in another way? Obviously source code parsing is completely broken although the source code is part of the libraries, neat and tidy. If it is a corruption problem then there should be a way to fix it e.g. clearing some kind of cache or re-building an index. The size of my log file is an awful 42MB. There is a lot of Wicket stuff in it, but I am not sure at all whether this is part of the problem. Please tell me what I should be doing. May be I should completely switch to Maven because Maven gets more support than default NetBeans ant based projects. So upgrading from 6.7 to 6.8 has not fixed it, and I am not keen to close it because 6.9 is out shortly.
Created attachment 97268 [details] Screen shot of editor window
Created attachment 97269 [details] log in zip file
Created attachment 97270 [details] Log in zip file
More info when it happens: I am in a debug session and I open a class via clicking on an entry in the call stack window. Just checking where it is loded from, I try File, Save As, and the file dialog is positioned at the file's package within the expected library component. Annotations all red, no source code navigation works, as if the file was opened in another context, say from a copy of the source files in the favorites window. Breakpoints in the file are ok. I can fix this temporarily: I copy the class name, close the class and re-open it via "Goto Type". Then all is fine, including my breakpoints. So it looks as if there is an action that activates (the missing) source code functionality, and that this action is missing if the source file is opened in a debugging session, from within a stack entry. When clicking on a call stack window entry, then the following additional log content gets written: INFO [org.openide.text.CloneableEditorSupport]: Outer callstack java.lang.Exception at org.openide.text.CloneableEditorSupport.openDocumentImpl(CloneableEditorSupport.java:870) at org.openide.text.CloneableEditorSupport.openDocumentImpl(CloneableEditorSupport.java:852) at org.openide.text.CloneableEditorSupport.openDocumentCheckIOE(CloneableEditorSupport.java:832) at org.openide.text.CloneableEditorSupport.openDocument(CloneableEditorSupport.java:814) at org.openide.text.DataEditorSupport.openDocument(DataEditorSupport.java:493) at org.openide.text.CloneableEditorSupport.open(CloneableEditorSupport.java:467) at org.openide.loaders.DefaultDataObject.open(DefaultDataObject.java:173) at org.openide.awt.ActionDefaultPerfomer.actionPerformed(ActionDefaultPerfomer.java:67) at org.openide.awt.ContextAction$Performer.actionPerformed(ContextAction.java:223) at org.openide.awt.ContextManager.actionPerformed(ContextManager.java:237) at org.openide.awt.ContextAction.actionPerformed(ContextAction.java:106) at org.netbeans.modules.openide.util.ActionsBridge$ActionRunnable$1.run(ActionsBridge.java:108) at org.netbeans.modules.openide.util.ActionsBridge.implPerformAction(ActionsBridge.java:83) at org.netbeans.modules.openide.util.ActionsBridge.doPerformAction(ActionsBridge.java:67) at org.openide.awt.GeneralAction$DelegateAction.actionPerformed(GeneralAction.java:218) at org.netbeans.modules.openfile.DefaultOpenFileImpl.open(DefaultOpenFileImpl.java:571) at org.netbeans.modules.openfile.OpenFile.open(OpenFile.java:72) at org.netbeans.modules.openfile.OpenFile.openFile(OpenFile.java:97) at org.netbeans.modules.openfile.OpenFileAction.actionPerformed(OpenFileAction.java:128) at org.openide.awt.AlwaysEnabledAction$1.run(AlwaysEnabledAction.java:139) at org.netbeans.modules.openide.util.ActionsBridge.implPerformAction(ActionsBridge.java:83) at org.netbeans.modules.openide.util.ActionsBridge.doPerformAction(ActionsBridge.java:67) at org.openide.awt.AlwaysEnabledAction.actionPerformed(AlwaysEnabledAction.java:142) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242) at javax.swing.AbstractButton.doClick(AbstractButton.java:357) at javax.swing.AbstractButton.doClick(AbstractButton.java:337) at javax.swing.plaf.basic.BasicPopupMenuUI$BasicMenuKeyListener.menuKeyPressed(BasicPopupMenuUI.java:341) at javax.swing.JPopupMenu.fireMenuKeyPressed(JPopupMenu.java:1370) at javax.swing.JPopupMenu.processMenuKeyEvent(JPopupMenu.java:1349) at javax.swing.JPopupMenu.processKeyEvent(JPopupMenu.java:1333) at javax.swing.MenuSelectionManager.processKeyEvent(MenuSelectionManager.java:439) at org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor.dispatchKeyEvent(ShortcutAndMenuKeyEventProcessor.java:288) at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:962) at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:841) at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:668) at java.awt.Component.dispatchEventImpl(Component.java:4502) at java.awt.Container.dispatchEventImpl(Container.java:2099) at java.awt.Window.dispatchEventImpl(Window.java:2475) at java.awt.Component.dispatchEvent(Component.java:4460) at java.awt.EventQueue.dispatchEvent(EventQueue.java:599) at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:125) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161) [catch] at java.awt.EventDispatchThread.run(EventDispatchThread.java:122) WARNING [org.netbeans.modules.java.source.tasklist.IncorrectErrorBadges]: Incorrect error badges detected, file=C:\prog\apache-wicket-1.4.6\src\wicket\src\main\java\org\apache\wicket\markup\ComponentTag.java. WARNING [org.netbeans.modules.java.source.tasklist.IncorrectErrorBadges]: Not PathRegistry controlled root: C:\prog\apache-wicket-1.4.6\src\wicket\src\main\java ComponentTag.java is the file I opened. and C:\prog\apache-wicket-1.4.6\src\wicket\src\main\java is the source component of the Wicket library of this project.
Sorry, but I will need a reproducible test case, information about the exact library setup, etc. to find out what is wrong and fix that. Thanks.
I really like making testcases - in fact most of my bugs have them. But with this bug, it seems too hard to doo. Too hard, really. At the moment, the bug does not reproduce. How can I make a testcase this way? It appears that some missing action, possibly due to another exception, prevents the IDE from functioning. So I will provide more information until it is enough to spot the bug. Please look at the exceptions above and in the attached log. FOr now, I am suggesting these warnings for examination (there are others): Not PathRegistry controlled root: C:\prog\apache-wicket-1.4.6\src\wicket\src\main\java This is the source root of my Wicket library. It should be registered. Here is the file: C:\Documents and Settings\Administrator\.netbeans\6.8\config\org-netbeans-api-project-libraries\Libraries\Wicket.xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE library PUBLIC "-//NetBeans//DTD Library Declaration 1.0//EN" "http://www.netbeans.org/dtds/library-declaration-1_0.dtd"> <library version="1.0"> <name>Wicket</name> <type>j2se</type> <localizing-bundle>org.netbeans.modules.wicket.library.Bundle</localizing-bundle> <volume> <type>classpath</type> <resource>jar:file:/C:/prog/apache-wicket-1.4.6/lib/wicket-1.4.6.jar!/</resource> <resource>jar:nbinst://org.netbeans.modules.wicket.library/libs/slf4j-api-1.4.2.jar!/</resource> <resource>jar:nbinst://org.netbeans.modules.wicket.library/libs/slf4j-jdk14-1.4.2.jar!/</resource> </volume> <volume> <type>src</type> <resource>file:/C:/prog/apache-wicket-1.4.6/src/wicket/src/main/java/</resource> </volume> <volume> <type>javadoc</type> <resource>file:/C:/prog/apache-wicket-1.4.6/apidocs/</resource> </volume> <volume> <type>maven-pom</type> </volume> </library> What strikes me is that it is <volume> <type>maven-pom</type> </volume> because I don't use this with Maven. Anyway, NetBeans should never fail to find these source files. Some exception before the first such failure, which is recorded in the log, in the same session could help identify the culprit that breaks the system.
I have said this before: If I change the resource file:/C:/prog/apache-wicket-1.4.6/src/wicket/src/main/java/ to a zip file with the same content then the problem disappears - always. It might have to do with Maven because it does not happen without maven projects in my system. It appears, and that is pure speculation, that the IDE grabs sources from Maven projects and gets confused with the path structure, the additional /main after src or something like that when it ascends the path (which I think it should not do).
If this can't reliably be reproduced even by the reporter, which I believe is the case as per the recent posts from bht, it does not qualify as P2. I'm sorry, but I'm lowering the priority.
I tried the following: -downloaded apache wicket 1.4.6, unpacked in /tmp/wicket. -created a library with classpath: jar:file:/tmp/wicket/apache-wicket-1.4.6/lib/wicket-1.4.6.jar!/ and sources: file:/tmp/wicket/apache-wicket-1.4.6/src/wicket/src/main/java/ -added the library to a J2SE project, used DropDownChoice, clicked on it -four different things happened depending on what I did on the filesystem: a) the DropDownChoice.java has been recognized as part of a Maven project, which was scanned and everything worked as I would expect (I did not have the slf4j library downloaded, which I solved by opening the Project [Ctrl-Shift-1] and choosing to dowload the libraries). b) deleted both /tmp/wicket/apache-wicket-1.4.6/src/pom.xml /tmp/wicket/apache-wicket-1.4.6/src/wicket/pom.xml and then the sources became part of the library, and their classpath was specified only by the library (not slf4j in my case). Navigation inside the source root worked OK. c) deleted /tmp/wicket/apache-wicket-1.4.6/src/pom.xml. Then the maven support got confused (not really surprising, IMO), and the source level for all the files was set to 1.3. Navigation inside the given source root still worked OK. d) deleted /tmp/wicket/apache-wicket-1.4.6/src/wicket/pom.xml, worked similarly to a). Cases a) and b) are the supported ones, and these worked for me reasonably. Cases c) and d) are a misconfiguration/user error, IMO. What is your exact setup? Thanks.
Thanks for trying this in spite of the fact that this is hard to reproduce. My setup is basic, and I did not delete anything. I never do things such as deleting only part of anything in a non-standard way. In addition, I have a Maven web project (not open) src/wicket-examples which should not matter. I typically have about 10 projects open but I can't say that this is the reason. Unfortunately I am running out of ideas - this is the most difficult NetBeans bug I ever encountered. I agree with the priority setting, but I would not want to close this. The evidence is in the log. I am hoping that I just get an idea out of the blue, or that you can see from the log history and the exceptions what is happening to build up a case. I am really surprised to see a log file of tens of MBs in a single working session. If I provide you with more information, which I am more than happy to do, then I am confident that will all look fairly standard. The fact that this re-appears across multiple versions of NetBeans and multiple complete new installations (I changed computers since the first occurence and re-installed for another reason) speaks for itself.
It appears this is caused by Maven projects serving as source code providers, if these Maven projects have missing dependencies. The difficult part is that NetBeans finds these Maven projects and gets confused by them although the ant project library settings provide all source code correctly by alternative paths.