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.
On a fresh install of NB 5.5.1 on windows XP with jdk1.6.0_01: create a standalone module, add an action using the wizard, accept all the defaults, in the performAction() method body type System.out.println("foo"); then select "Install/Reload in Target Platform" from the right-click menu in the Projects window. Once the target platform is running verify that firing the action prints "foo" in the output window on the development platform. Change "foo" to "bar", then "Install/Reload" again. The target platform claims it's reloaded the module in the status bar, but fire the action from the menu and it still prints "foo". The UI is holding onto the old class. Now close the target IDE, close the development IDE, then restart the development IDE and repeat the process. Now the module reloads correctly every time. This odd behavior seems to persist in 6.0M9.
Reproducible. You do not need to restart the development IDE, only the target platform.
I suspect a problem in MenuBar, DataShadow, InstanceDataObject, or core/settings, but I am not sure how to track it down more precisely. The SFS does seem to be firing changes, but they are not propagated to menu items at least. To reproduce: 1. Using a dev build on a fresh user dir, make a new standalone module. 2. In its layer, add <folder name="Menu"><folder name="F"/></folder>. 3. Make an action in it in the F menu. Choose label "A". 4. Press F6 to run w/ reload. Note F > A menu item. 5. Change folder name in layer to G, change action name in bundle to B. F6. Now have F > A and G > A. 6. Change folder to H, action to C, F6. Now F > A and H > A. 7. Shut down target app, F6. H > C. 8. Change folder to I, action to D, F6.
Just found that after step #5, the SFS does in fact contain both Menu/F and Menu/G folders.
Found it with the help of jrunscriptin: sfs = org.openide.filesystems.Repository.getDefault().defaultFileSystem SystemFileSystem[org.netbeans.core.startup.layers.SystemFileSystem@190d1e8] java.util.Arrays.asList(sfs.userLayer.findResource("Menu").children) [MultiFileObject@970e7c[Menu/G]] java.util.Arrays.asList(sfs.installationLayer.findResource("Menu").children) [MultiFileObject@458364[Menu/F], MultiFileObject@1b54eb0[Menu/Versioning], MultiFileObject@4134e0[Menu/GoTo], MultiFileObject@f673cc[Menu/Edit], MultiFileObject@2c65f5[Menu/File], MultiFileObject@d9dbd1[Menu/RunProject], MultiFileObject@ee7cee[Menu/Refactoring], MultiFileObject@14c0761[Menu/BuildProject], MultiFileObject@7895d8[Menu/Tools], MultiFileObject@b5c12e[Menu/Source], MultiFileObject@9dc1bb[Menu/Help], MultiFileObject@11a0d8b[Menu/View], MultiFileObject@16f2b7f[Menu/Window]] NbInstaller tried to insert or remove the module's layer into the right MLFS - user or installation - according to the reloadable flag (see issue #19458). However, when first reloading a module, its reloadable status is changed from false to true _before_ the call to ModuleManager.reload(), so it is uninstalled from inst - a no-op - then installed fresh into user, making a dupe entry. When the target platform is restarted, its flag is true from the start, so reload correctly removes and adds both in the user layer. Fix is simply to remove a layer from *both* inst and user when disabling the module; should not hurt to try to remove a layer from a MLFS that it does not exist in anyway. Workaround is to restart target platform, as previously mentioned; if you do a clean build of the module, the problem reappears until the first restart after a reload. Checking in NbInstaller.java; /shared/data/ccvs/repository/core/startup/src/org/netbeans/core/startup/NbInstaller.java,v <-- NbInstaller.java new revision: 1.45; previous revision: 1.44 done