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.
Use a platform dev build w/ fix for issue #29577. Run AU and download some module w/ a help set, e.g. usersguide. Restart. Check help menu - fine. Run AU and download DB Explorer (also has a help set). Restart. DB Explorer help not there. Even after restarting several more times. With -J-Dorg.netbeans.core.LookupCache=0, easy to diagnose: after 2nd restart, you get an initial cache hit - the new module is *not* installed yet - then the new module is installed - but lookup is not refreshed for some reason at that point. So lookup remembers all instances of HelpSet and refuses to "see" the new one. After a restart, again get a cache hit, same as before. Workaround: touch some module JAR file, or delete $userdir/cache/, etc., and restart.
I think I figured it out. One-line patch! Pretty cryptic. FolderLookup.ProxyLkp is deserialized properly as part of the lookup cache, and binds itself to a FolderLookup instance for the correct folder. FolderLookup's super constructor calls FolderInstance, which creates a listener for DataFolder.PROP_CHILDREN and attaches it to the folder. However, if there is no particular reason for that folder to be opened otherwise (e.g. Services/JavaHelp/), DataFolder notices that no one ever *asked it* for the list of children, therefore it never fires PROP_CHILDREN even when child files are added etc.! So the simple fix is to ask for the folder's children when deserializing the FolderLookup. I tested it and it works. ---%<--- Index: openide/src/org/openide/loaders/FolderLookup.java =================================================================== @@ -302,6 +302,7 @@ DataFolder df = (DataFolder)ois.readObject (); String root = (String)ois.readObject (); + df.getChildren(); // #30494 fl = new FolderLookup (df, root, true); fl.lookup = this; ---%<--- This fix will probably revert some of the startup time improvement that #20190 offers, since now all of the DataObject's under Services/ need to be created on every startup, even though e.g. .settings files need not be parsed. But I don't know of any other good way to ensure that you hear about changes in the contents of a DataFolder (additions, removals, reorders) besides asking for the children once before you attach the listener. I guess you could attach a FileChangeListener to the folder, though this seems kind of a hack - DataFolder is supposed to encapsulate the filesystems layer and provide a higher-level interface in terms of DataObject's. Increases code complexity etc. Alternative is to have DataFolder fire changes even before getChildren is ever called, but this seems wrong too; our normal conventions for beans usage says that you need not fire changes on a property whose getter has never been called - no one knew what the original value was, therefore they do not care if it changes. Or could have some method (package-private?) on DataFolder to the effect of "starting listening for changes now, damn it!". Clearly a hack. Ideal would be to have DataFolder.getChildren return a java.util.List with lazy members, i.e. DataObject's not constructed until you call List.get(int) etc. However that is a much bigger API change (compare Tim's thoughts about lazy folders). Anyone think one of the above alternate fixes would be preferable to the patch shown? If not I will commit it.
committed Up-To-Date 1.23 openide/src/org/openide/loaders/FolderLookup.java
verified