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.
Summary: | Lookup cache not invalidated after installing new module from AU | ||
---|---|---|---|
Product: | platform | Reporter: | Jesse Glick <jglick> |
Component: | Lookup | Assignee: | Jesse Glick <jglick> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | dstrupl, jtulach, pnejedly, tboudreau |
Priority: | P2 | Keywords: | PERFORMANCE |
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 20190 |
Description
Jesse Glick
2003-01-29 20:32:21 UTC
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 |