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.
Using 020418_1 EE kit on Windows 2000 JDK 1.4.0 To reproduce: 1) Start the IDE with a clean user directory 2) After closing the registration and welcome dialog, type the F1 key (this must be the first action) Result The Help window opens without any contents and the Help Contents and Help Sets -> menuitems are disabled Warning: the JavaHelp topic ID org.netbeans.core.windows.WorkspaceSwitcher was not found. Warning: the JavaHelp topic ID org.netbeans.core.windows.MainWindow was not found. If the IDE is restarted then those menuitems reappear
I am adding the following from Ken Dyall, who had similar problems with Solaris. Note that this behavior is different from the 020416 build, where the help behavior worked acceptably. the following is true for the 020418_1 build, solsparc_ee. * The same behavior is seen as John filed in his bug. New userdir, start IDE, press F1, help disabled. * New userdir, start IDE, choose Help > Helpsets > Solaris .., help disabled. * New userdir, Start IDE, mount filesystem, select performance experiment, press F1, help disabled. Subsequently choosing a C executable, choosing Debug > Load Program gets into the Java debugger instead of the dbx debugger. In all cases the default message about the help is presented: This window contains the master set of all installed documentation. You can use the navigators to the left to browse the IDE's complete table of contents and index, and perform whole-documentation search on the index and full-text search. Attached is Ken's log of the tests on the 020417_02 build.
Created attachment 5477 [details] Log of tests for Build 17
See also issue 21157
there are two unrelated issues 1) pressing F1 displays Help frame with unexpected contents F1 displays the context help for the UI component under the mouse cursor not the UI component currently focused. This has been changed for NB 3.4dev. See issue 21157. I proposed to integrate the fix into 3.3.2/Orion but Patrick and others disagreed. 2) the "Help Contents" and "Help Sets" menuitems are disabled this needs more investigations
Build 020418_1 EE isn't avaible yet here in Prague. I tried to reproduce this on 020417_2 EE and CE on W2k and Solaris 5.8 without succes - everything worked as expected. However I tried it on Solaris 5.9 on default jdk1.4.0 and there I saw disabled help menuitems, that was caused by issue #22455. When I used Jesse's patch it worked fine. So not sure, but IMO is this issue caused by older jhall.jar on the classpath. Jesse?
I have no idea. If someone knows how to reproduce this reliably, let me know...
According to log in issue #22455, no help sets are found at all. Lookup problem?! Does anyone know for sure if this problem only began happening in a certain build? Bob May seems to be saying that it was broken between the 16th and the 18th; can you confirm this?
I reproduced the problem on linux too, build 020417_2 EE. I'll attach log. There was no other jh.jar on classpath besides the NetBeans one.
Created attachment 5489 [details] log from javahelp=0
Created attachment 5490 [details] log from EE when executed with -J-Dorg.netbeans.core.Help=0 on Solaris 5.9
Confirming that on EE build 020416_1 this problem doesn't occur.
I'm unable to reproduce just by updating sources and making an EE build. I see a couple problems with JWD and DB Schema helpsets, but these are apparently known, and the rest of the help works fine. Maybe I need that specific build?
I am also unable to reproduce by: 0. Running Linux, 2.4 kernel. 1. Get FFJ-dev-020417_2-f4j_ee.zip. 2. Cd to fresh dir /tmp/FFJ-dev-020417_2-f4j_ee/ and unpack. 3. rm -rfv /tmp/testme 4. ./bin/runide.sh -userdir /tmp/testme -J-Dorg.netbeans.core.Help=0 5. Finish when prompted to import settings. 6. Select MDI mode, then Finish setup wizard. 7. Never Register, Finish. 8. Do Not Show Welcome Screen, Close. 9. Alt-H and C. Master help appears with all help sets. Running JDK 1.4.0; same with 1.3.1_03.
Wait, now I seem to have got it... not sure what is different: 1. Started in ~ (different working dir). 2. Left it in SDI mode. 3. Did not choose "Do not show...". 4. Used mouse only, not keyboard shortcuts.
In a build where it is broken, none of the help set reference files in /Services/JavaHelp/ have InstanceCookie's - the XML processor has never been attached to them. But modules added after the IDE is started show help sets fine. So it is some sort of startup problem. I can find nothing in the CVS diffs during this day that would explain why this suddenly stopped working, nor do I have any explanation of what is wrong in EE specifically.
It seems difficult to reproduce, I am unable to get it to happen consistently.
I have a strong suspicion that the actual event causing the regression was some change in the persistence modules, put back by Anil Gaur during the period in question. Specifically the attached stack trace may explain something. However this just seems to have been the trigger; the actual bug lies somewhere in lookup, still under investigation.
Created attachment 5491 [details] Stack trace probably explaining why bug appeared when it did (INF #6751)
I think I have it down. The problem was that org.netbeans.core.xml.XML registered org.netbeans.core.xml.FileEntityResolver to lookup; FER was necessary for things like help set reference .xml files to work. XML.init() added it to instance lookup for NbTopManager. But this lookup does not become ready until sometime around modulesClassPathInitialized. Persistence module recently began to search for help sets, or at least get the instance cookie on some help file, during startup, in its loader initialization. I don't know why you would try to make help sets forcibly during initialization, when the core tries hard to not initialize help sets until someone actually shows help, but maybe Rochelle can explain more here - I don't have sources to this module, so this is just a guess. Anyway, /xml/lookups/ resolution is a critical part of the IDE's infrastructure and it is not safe to delay it until modulesClassPathInitialized. So I prepared a patch which puts the FER instance directly into TMLookup, where it will be available immediately. The patch appears to cure the bug. I would appreciate it if QA would help test it however, since I am not able to reproduce the bug without the patch 100% of the time.
Created attachment 5492 [details] Proposed patch - also delete unused core/src/org/netbeans/core/xml/XML.java
Created attachment 5493 [details] Binary patch JAR for orion_fcs branch; put in lib/patches/ to use
Updating the description to be more accurate. Part of the problem is that org.openide.loaders.Environment does not expect the lookup on Environment.Provider to ever change. If anyone asks for InstanceCookie on an XML file with an /xml/lookups/-registered DTD before FER is added to Lookup, he will get nothing - and no else will later, either, because XMLDataObject now things there is no environment provider and doesn't check again. This is just what the persistence module seems to have done. Core developers, I would appreciate a review of the patch. I propose to put it into 3.3.2 although it changes a fairly basic part of the timing of lookup which ought to be better tested. Even if the only trigger for the bug were the persistence module, the persistence module is not doing anything illegal (though it is very unwise from a performance/startup time perspective), and some other module could legitimately do something that would trigger the bug too. When triggered, the effect is severe: broken help, perhaps other things broken as well.
Jesse, thanks for the investigation. Sorry, I never noticed the exception stack trace - that should have given me a clue. Here's some more info: 1) I can reproduce this every time by loading my modules (autoload + lightweight user) into a FFJCE build and then pressing F1 on one of my nodes. I'll try your Orion patch and let you know. 2) I wasn't intentionally trying to do stuff on loader initialization, but I guess I was =). I was trying to cache a static final reference to the parent help set in one of my utility classes so I could search for branded type ids as we discussed on nbdev a while ago. The alternatives I see are: add a synchronized static get method which initializes it if null or get it every time. Based on performance at loading and during run and the consequences of this bug, do you suggest I change to one of the other strategies?
To Rochelle: The stack trace I inserted for debugging, it was just to show when and where help set ref files were being first used. Note that the XML file in question is the usersguide help set. To your #1: that is good, because it helps confirm the source of the problem. To your #2: I am not sure of the details of your module, but try to be as lazy as possible - specifically, you should not instantiate any help sets until help is requested on something. More precisely, getting the InstanceCookie from a helpsetref XML file early is more or less OK, since this will happen anyway when lookup is being used - the system has to find out the XML file *is* a helpsetref - but don't call instanceCreate until you have to. In the NB JavaHelp infrastructure, the actual HelpSet's are not created until help is really displayed.
I tried the patch in my userdir/lib/patches and it didn't help. Do I need to put it in the install/lib/patches?
Yes, please use lib/patches/ in the installation directory. You should see it at the front of the CLASSPATH printed to the console.
I saw it at the front of the CLASSPATH before too. It doesn't work even if I install it in the installation dir's lib/patches.
I'm not sure if this is a hint, but my module (and its help) are installed in my userdir, not the global install.
On Win2k, The patch fixes the problem, to me. I installed 020418_2 EE, using a clean userdir then copied the patch, 22612.jar to installdir\lib\patches, started the IDE, started Help by typing the F1 key and found that the Help contents are there and the Help menuitems are now working. Next, just to make sure, I removed the userdir and patch, restarted the IDE and tried to open Help using F1 key. the Help contents fail to load and the Help menuitems are disabled.
What next? It works for you but not for me =). I'm interested in changing my code anyway for performance reasons, but right now I'm providing a good test case for this problem. Even if I fix mine, another module might do the same thing, so we should try to figure it out.
Jesse said: "When triggered, the effect is severe: broken help, perhaps other things broken as well." I think I can confirm that; the last couple of days several people have noticed that our C++ debugger has been broken; when selecting a C++ program and starting the debugger, the wrong debugger (the JPDA debugger) is started instead. I have no idea why that would be - our code hasn't changed in a while - but it -does- use Lookup to get the debugger type (very similar to debuggercore's RunToCursorAction getDebuggerType() method - I would have used that one if it had not been package private) so I suspect that this bug is the cause for Lookup returning the wrong thing. I've asked people in my group to try your patch to see if they can reproduce the problem.
Thanks Tor. I don't know offhand why Rochelle's poking at a Services/JavaHelp/*.xml would affect *other* helpsets, much less your debugger types, but I guess it is possible - didn't get that far in the analysis of the bug's effects. Please do see if this patch solves such problems, and also see if these problems occur only with the (presumably problematic) persistence module.
Yes, I've been told that the patch fixes the problem. I've never been able to reproduce the problem myself - because I always run the IDE with most modules disabled. Thanks to this bug report I've realized that I need to run with the full EE set enabled - and persistence in particular - so I'm cvs updating right now. But cvs updating the full EE cvs tree over a DSL line takes forever :-) Once I can reproduce the problem myself I'll check this more carefully. I've been thinking I should go and use lookup more (to communicate between the cpp module and the ifdef module the debuggertype to use for native executables, instead of registering this during module startup) and this was going to be my incentive. Of course, since the development complete deadline is tonight at midnight, ... I'll see. I've got some other bugs I'd like to address too.
I spoke to Jesse offline and then did some testing and here are the results so far: If I use lazy initialization in my code instead of a static final variable, Jesse's patch is not needed. Global vs. local installation and the presence of the system/Modules xml file don't matter. As soon as I turn merge=false for my helpset, the problems reappear, even with Jesse's patch. I'll deliver a patch for EE to Tor, John and Bob with my lazy initialization (merge=false was never checked in). We'll see if that fixes the EE problems. Meanwhile, we need to investigate merge=false problems and if Jesse's patch is required anyway. As he said, I didn't do anything illegal and if another module does something like this with such drastic consequences, we may need the fix anyway.
Fixes supplied by Rochelle solve the following Help problems, all related to first use of help (=help loading) after the IDE initializes. 1) F1 help on an Explorer node. 2) Selecting Help contents (either mode) It does not work when main window (toolbar, for example) is either moused over OR selected and f1 is pressed. Jesse's patch from today did not seem to affect the help.
Created attachment 5498 [details] Picture of help in ID after mouseover or clicking on main window and pressing F1 and getting Warning: the JavaHelp topic ID org.netbeans.core.windows.MainWindow was not found.
One more comment - not really related ot the help problem, but perhaps it helps shed light on the root problem? I tracked the debugger problem down, and found that it wasn't Lookup that was broken - Lookup was returning all the debuggertypes correctly. It was the data object mimetime lookup that was broken. Calling obj.getPrimaryFile().getMIMEType() on the data object that I'm passed, produced mime type "content/unknown" where it usually knows better. This is what was causing the debugger to get tripped up because it uses mime types to decide if it can debug the given data object. I'm not sure if this is the reason, but I noticed that when I run EE with -J-Dnetbeans.debug.exceptions=true I get hundreds of exceptions of the following form - and as you can see from the stacktrace they -relate- to mime types. But the odd thing is - both Jesse's patch, and Rochelle's updated persistence modules, fixes the problem - the correct MIME type is returned! Fri Apr 19 17:04:19 PDT 2002: java.io.FileNotFoundException: JAR entry org/netbeans/modules/j2ee/impl/org-netbeans-modules-j2ee-server-above-regular.txt not found in /home/tor/ifdef/ffj/f4j_all/f4jbuild/firststart/modules/autoload/locale/j2eeserver_f4j.jar java.io.FileNotFoundException: JAR entry org/netbeans/modules/j2ee/impl/org-netbeans-modules-j2ee-server-above-regular.txt not found in /home/tor/ifdef/ffj/f4j_all/f4jbuild/firststart/modules/autoload/locale/j2eeserver_f4j.jar at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:95) at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:105) at java.net.URL.openStream(URL.java:955) at org.openide.filesystems.XMLFileSystem$FileObjRef.getInputStream(XMLFileSystem.java:818) at org.openide.filesystems.XMLFileSystem.getInputStream(XMLFileSystem.java:287) at org.openide.filesystems.XMLFileSystem.access$300(XMLFileSystem.java:89) at org.openide.filesystems.XMLFileSystem$Impl.inputStream(XMLFileSystem.java:624) at org.openide.filesystems.AbstractFileObject.getInputStream(AbstractFileObject.java:165) at org.openide.filesystems.MIMESupport$CachedFileObject.getInputStream(MIMESupport.java:154) at org.netbeans.core.filesystems.MIMEResolverImpl$Type.accept(MIMEResolverImpl.java:538) at org.netbeans.core.filesystems.MIMEResolverImpl$Type.access$1500(MIMEResolverImpl.java:423) [catch] at org.netbeans.core.filesystems.MIMEResolverImpl$FileElement.resolve(MIMEResolverImpl.java:389) at org.netbeans.core.filesystems.MIMEResolverImpl$FileElement.access$000(MIMEResolverImpl.java:375) at org.netbeans.core.filesystems.MIMEResolverImpl$Impl.findMIMEType(MIMEResolverImpl.java:107) at org.openide.filesystems.MIMESupport$CachedFileObject.resolveMIME(MIMESupport.java:137) at org.openide.filesystems.MIMESupport$CachedFileObject.getMIMEType(MIMESupport.java:126) at org.openide.filesystems.MIMESupport.findMIMEType(MIMESupport.java:51) at org.openide.filesystems.FileUtil.getMIMEType(FileUtil.java:586) at org.openide.filesystems.AbstractFileObject.getMIMEType(AbstractFileObject.java:147) at org.openide.filesystems.MultiFileObject.getMIMEType(MultiFileObject.java:441) at org.openide.filesystems.MultiFileObject.getMIMEType(MultiFileObject.java:441) at org.openide.loaders.ExtensionList.isRegistered(ExtensionList.java:130) at org.openide.loaders.UniFileLoader.findPrimaryFile(UniFileLoader.java:62) at org.apache.tools.ant.module.loader.AntProjectDataLoader.findPrimaryFile(AntProjectDataLoader.java:111) at org.openide.loaders.MultiFileLoader.findPrimaryFileImpl(MultiFileLoader.java:232) at org.openide.loaders.MultiFileLoader.handleFindDataObject(MultiFileLoader.java:65) at org.openide.loaders.DataLoader.findDataObject(DataLoader.java:220) at org.openide.loaders.DataLoaderPool.findDataObject(DataLoaderPool.java:363) at org.openide.loaders.FolderList.createBoth(FolderList.java:576) at org.openide.loaders.FolderList.access$600(FolderList.java:43) at org.openide.loaders.FolderList$2.run(FolderList.java:259) at org.openide.util.Task.run(Task.java:152) at org.openide.util.RequestProcessor$ProcessorThread.run(RequestProcessor.java:622)
Bob, your screen shot does not look like any cause for concern - it just looks like that help ID is not mapped. You're sure it's mapped, and the ID is only not found under some conditions?
Yarda says that basically the same code as my patch is already in the trunk, for roughly similar reasons.
Probably also affects the Java Developer Connection bugs 4671978 and 4671760. This has bigger impact than originally thought, so upgrading to P1.
Created attachment 5507 [details] ZIP of module to exercise bug; unpack under installation
I tried to make a trivial module to exercise the bug. It just has a dummy data loader whose initialize() method: 1. Gets Services/JavaHelp/org-netbeans-modules-usersguide-helpset.xml 2. Gets its XMLDataObject and asks it for InstanceCookie 3. Asks for IC.instanceName() 4. Asks Lookup for all instances of Executor Unpack the ZIP file on top of a current CE build so that the test module will be part of the build. With the binary patch for this bug, all is well. "javax.help.HelpSet" is printed. No Executor's are found, but they are found later on in the IDE. Without the binary patch, this module throws an NPE - no InstanceCookie on the XML file. When the IDE is opened, the usersguide help set is not present. However other help sets and services are present. So while I can verify that the patch fixes the predicted symptom of an InstanceCookie (etc.) not being found on a particular XML file that is accessed too early during IDE startup; I cannot verify that it fixes any bug relating to *all* help files going dead, or more generally to Lookup as a whole being broken. Does anyone have a cleanly self-contained way to reproduce the massive Lookup failures I have heard reported in association with this bug? If so, I can try to investigate them.
Seem to have some agreement that the symptoms of this and related bugs are fixed by the revised persistence module. Still unknown why the serious symptoms occurred at all.
In a build with the "bad" persistence and no patch, I can reproduce other symptoms such as Ant scripts appearing as plain XML files.
So, what happens now? Persistence is not "bad" anymore, but any module (third party or otherwise) can mess up the IDE pretty badly. If Yarda says an equivalent change has been made in the trunk, it sounds like it has been reviewed already. Should this be applied to the 3.3.2/orion_fcs branch?
Re the attachment sent by Bob and subsequent comments by Jesse: It appears that using F1 in the main window did not work before this bug was filed. I tried EE solsparc Build 020416_1 (open IDE with clean userdir, default installation, mouseover main window title bar, press F1) and found the same behavior as in the later builds that had the F1 problem.
If you start FFJ using the same userdir as before (the default), and you were using the dbx Debugger in the previous session, the Java debugger window comes up both as itself (small Debugging Window) and then a larger Debugging Window comes up on top of it that should be the dbx Debugger window, but is a hybrid of that window and the Java debugger window (both tool bars, no tabs, etc.) When you start debugging a SOlaris Native Language program, the larger window displays the correct contents and the Java debugger tool bar goes away, but the window still does not have tabs, and the smaller Java debugger window remains displayed.
Tested build #020418_1EE and #020422_1EE on jdk1.4.0 on Solaris 5.9. #020418_1EE without patch - the problem with help sets seen everytime with the patch - problem doesn't occur anymore #020422_1EE - contains fixed persistence problem without the patch - everything works ok with the patch - everything works fine too Also verified behaviour with Jesse's experimental module w/ and w/o patch. Agreed that the patch should be applied even if the persistence problem is fixed. Yarda has reviewed it already. Within this issue are mentioned many different problems. Please check if they are fixed by the patch, if not then please evaluate and file them as separate issues.
Has the patch been checked in yet? I just tested Build 020423, solsparc ee, and saw the dbx debugger and help problems with a clean userdir. To reproduce: no proxy server, all defaults, never register. Start ide, mount filesystem, choose C executable, choose Debug > Load Program. Java debugger opens. Then choose Help > Contents. Topic ID not found, help disabled.
There are 2 patches being discussed here: 1) Jesse's patch to the core - I don't think this is checked in yet 2) My patch to persistence - This is checked in to the iplanet cvs repository, but is checked in as a jar (not by me) to the ffj cvs repository. That was done last Friday by Anil (Gaur) but was apparently an older version. So, the short answer, is no, it's not in yet.
Forte for Java, EE v. 4.0 (Build 20020424-1313) looks like Rochelle patch is active - web.xml data object (based on xml data object) works - but you can not open the runtime/"server registry" node and NPE is fired (see 22644) looks like same problems, because CE is OK and this NPE occures only in EE
the last problem was caused by different bug (22744) the last EE build with the patch of the 22744 works perfectly, so it looks, the Rochelle patch works
My patch was checked in last night. Now the question is - what about Jesse's patch?
I am in the dark as to what was wrong with issue #22644, but Damian I will take your word for it that it was fixed in some other way... So I think it would be advisable to integrate the patch I attached here before: - Rochelle's old persistence code was not illegal acc. to APIs, yet caused incorrect behavior without this patch - my demo module shows that w/o the patch, incorrect behavior is possible (contrary to API contracts) after making a not-at-all-obscure change to a module - according to QA, the patch is not known to harm anything in current EE code, even if it is not necessary for visible bugs I still do not know exactly how Rochelle's code w/o this patch could break all of Lookup (only was able to trace cause of breakage of *one* file).
Using 020424_1 kit on Solaris 8, JDK 1.4.0 ... If the Toolbar is selected and the F1 key is pressed, Most helpsets are loaded (after a FEW minutes) except for this warning occurs ... Warning: the JavaHelp topic ID org.netbeans.core.windows.MainWindow was not found. (Web Services and DB Schema help set menuitems are disabled - a BugTraq bug was entered for Web Services Help)
Other than the warning, which I mentioned in the previous comment, this bug appears to be fixed, more testing is needed though.
Jesse, everyone seems to be in agreement that your patch is correct. No side-effects have been reported so far. Please check it in.
I'm not using Jesse's patch with 020424_1. Rochelle's patch is in this kit since she checked it in. I haven't yet checked other problems that occur without including Jesse's patch in this kit, yet.
Regarding "Warning: the JavaHelp topic ID org.netbeans.core.windows.MainWindow was not found." I have added this ID to the usersguide map file, so this warning should no longer appear.
Re John and Patrick's comments on 4/25: the problem of pressing F1 in the main window (toolbar, title bar, menu bar) and the mapid not being found predates this bug and is not related to it. I believe Patrick's fix should address it.
Committed: Checking in NonGui.java; /cvs/core/src/org/netbeans/core/NonGui.java,v <-- NonGui.java new revision: 1.49.2.2.4.2; previous revision: 1.49.2.2.4.1 done Checking in Plain.java; /cvs/core/src/org/netbeans/core/Plain.java,v <-- Plain.java new revision: 1.21.20.1; previous revision: 1.21 done Processing log script arguments... More commits to come... Checking in lookup/TMLookup.java; /cvs/core/src/org/netbeans/core/lookup/TMLookup.java,v <-- TMLookup.java new revision: 1.17.24.1; previous revision: 1.17 done Processing log script arguments... More commits to come... Removing xml/XML.java; /cvs/core/src/org/netbeans/core/xml/XML.java,v <-- XML.java new revision: delete; previous revision: 1.3.40 done
I have been testing Build 020424_2. In 5 launches of the IDE, with and without a clean userdir, I got the dbx debugger for a C program every time. In 5 launches of the IDE, with and without a clean userdir, I found no F1 help problems. Launching the IDE with a clean userdir, both Help > Contents and Help > Helpsets > SNLS Help worked.
I also verified 020425 kit on both Solaris and Win 2K. This has been fixed.
Marking as closed. - John Baker
Note: affected source code is in core, not openide.