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.
[aug 31 qbe and dev sep 12] Sometimes after reinstalling a module (an example module in my case, and using JAR Packager + apisupport to reload) the executor types are not found. They appear correctly under Executors, with the correct InstanceCookie etc., but do not appear in lookup nor in the services registry. Changes made to the Executors folder do not trigger a refresh. At other times the services do appear correctly. They are implemented with a .settings file in the usual style (Services/Executor/ with SystemFileSystem.localizingBundle, .icon, .layer=project). I do not have the projects module installed, if it matters. After restarting the IDE they generally appear. Sometimes it is OK even after a reload; could be some sort of timing issue.
Still open in [dev sep 23], this time from apisupport.
*** Issue 15979 has been marked as a duplicate of this issue. ***
Priority raised due to large impact.
Well bug with "sometimes" is often hard to fix. I tried the issue #15959 and it seems to work. Because these bugs are duplicate. I am going to close this one too.
This is still broken for me in [dev oct 5], at least the first time I tried it. Ran openide/build.xml:example-minicomposer-test once; minicomposer was built and installed. Click on some Java class; in the Execution tab, External AU Player and Internal AU Player appear. Run the reload target again; click on some other class; players are no longer there. They are still listed in Execution Types. You can if you like make a copy of them (e.g. New Executor ...) and this will appear in the pulldown of available executors, but not the ones installed by layer, until the IDE is restarted.
Fix of issue 11965 should fix this bug too.
This does appear to be fixed in [dev oct 8]. (The original problem was not 100% reproducible but I have tried reloading a few times and the services are always in the drop-down list, so I think it is fixed.)
When reinstalling a module (By using API Support on .jar file), which installs a Debugger Type. The debugger type doesn't appear in properties of a file (Data Object). But it appears under Debugger Types in Options. It happens always. (I've tryied even on a simple module with a debugger type for testing)
I'll try to reproduce it but I am downgrading the priority. Likely this issues does not prevent us from releasing 3.3?
It is a bug in InstanceDataObject - it returns null even it should not. I am attaching log from FolderInstance. Please investigate why the IDO returns null.
Created attachment 4257 [details] The log from -Dorg.openide.loaders.FolderInstance=-5
Presumably a timing problem with changing the instance file vs. changing the module enablement state. I am not sure this is P2 if it only affects module reloading. Anyway fixing it for 3.3.1 is probably not reasonable. BTW now is the time to decide whether to change module enablement + classloader change firing behavior for 3.4, it seems a lot more code relies on details of this than it was planned to support, so it ought to be more deterministic, probably documented as synchronous. This should help simplify logic in settings code.
Here is what I found out. At the time the FolderInstance obtains PROP_CHILDREN caused by adding the module layer the ModuleInfo is not accessible through the Lookup yet. So IDO does not provide InstanceCookie. We can either fix/improve the module system as Jesse suggested or I can implement workaround in IDO binding IDO with ModuleInfo later when it is accessible and fire PROP_COOKIE. Lowering priority to P3.
We should probably do both, actually.
Jesse, is it really necessary to implement the late binding when the module system will be synchronous? Why?
I'm not sure what you mean by late binding but it should not be necessary. I just meant that IDO should continue to fire PROP_COOKIES if a module is installed or uninstalled and the IDO remains where it is.
*** Issue 16980 has been marked as a duplicate of this issue. ***
By 'late binding' I meant binding IDO with the ModuleInfo later (added PropertyChangeListener) when it is accessible through the Lookup and then firing PROP_COOKIE. Present implementation does not provide ModuleInfo in the Lookup when the layer of an installed module is added to the default filesystem.
I've checked out the issue again using the reworked settings framework and find out the PROP_COOKIES is fired correctly by IDO now, but the Lookup still does not refresh properly. David can you take a look at it please?
Hi, I have tried following test in DynamicJava from Scripting console: import org.openide.util.*; import org.openide.compiler.*; l = Lookup.getDefault(); r = l.lookup(new Lookup.Template(CompilerType.class, null, null)); r.allInstances(); When repeating I have just executed the last line. Then I tried to 1. move some compiler definitions to the project layer 2. repeatedly disable/enable the module containing the compilers The returned instances were always ok (and were indeed different after re-enabling the module). So I am closing this as fixed. If you disagree please reopen and add steps (or test) demonstrating the problem. Thanks for your time.
Not able to reproduce in [dev jun 26] after reinstalling minicomposer example a couple of times. Perhaps fixed by something else.
verified