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.
[dev aug 8] If module A defines some interface class I, along with a static method to create instances of I; and asks lookup for a Lookup.Result based on I as a template and listens to changes; and module B depends on A and has in its layer a methodvalue instance creating an I in the Services/ folder: it can happen that after reloading A and B in test mode, during the restore of B's layer, FolderLookup will refresh and fire a result change, in which one of the results is of type I but of the old class, not the new one in the currently installed A, causing a ClassCastException. Suspect that the problem is that the old module still holds a Lookup.Listener and when the module is reinstalled, the old listener is notified of the new lookup results. This is partially the fault of the module (it should explicit detach the listener and dispose of the result object upon uninstallation since any further changes will be useless); but also the fault of lookup: the Lookup.Result was created with an old class as template and should never yield instances of the new class, even if the name is the same, or the semantic contract of lookup is violated. I suspect either AbstractLookup or FolderLookup is at fault: perhaps InstanceDataObject.instanceOf, in this case checking the instanceOf file attribute, thinks that the instance is assignable to some requested class when it fact it is not (because the requested class is the old version and the instance will be of the new version), and then no part of the lookup chain actually verifies that the instance is of the correct type after it is created. After inserting a small patch into AbstractLookup.R.allInstances which actually checks whether the instances it is about to return are assignable to the template class, reproducibly found that they were not (see attached stack trace and a diagnostic patch).
Created attachment 2168 [details] Example patch to AbstractLookup to alert you when it happens
Created attachment 2169 [details] Sample stack trace from similar patch which terminates lookup upon error
We can fix allInstances but it is probably hard to fix allItems...
This is definitively bug of InstanceDataObject which has to improve its behaviour: 1. if the instanceOf (...) is called for a class loaded by some module, the InstanceDataObject has to listen for that module to be still enabled 2. if the module is disabled it should create new InstanceCookie and fire PROP_COOKIE change then the FolderLookup will refresh itself and remove the previous Pair (with the old cookie and class) and place there a new one
This behavior is already implemented in IDO for .settings containing <module> tag.
Note that in the case for which I filed this, .instance is appropriate and not .settings (the user is not expected to customize the instance at all). Also note that when a module is reloaded, PROP_ENABLED will probably not be fired, since after the module manager lock is released, it is still enabled and nothing has changed. More accurate would be to fire a PROP_CLASSLOADER; currently this is not part of the APIs (since getClassLoader() is not defined on ModuleInfo). Or PROP_OWNERSHIP since ownership of classes *is* defined already.
Still broken in [dev sep 17]
I see similar behaviour in Autoupdate Types: In UC wizard I use: TopManager.getDefault ().getServices ().services (AutoupdateType.class); to get all AU types. But after following steps I got nothing: 1.Run IDE and start the UC wizard - there are 3 Autoupdate Types 2.Cancel the wizard 3.Uninstall the AU module (set Enabled to False in Tools| Options| IDEConfiguration| System| Modules| Infrastructure| AutoUpdate) 4.Install the AU module (set Enabled to True in Tools| Options 5.Run UC wizard and there will be the empty list of AU types, but there are 3 AU types visible in Tools| Options Note: It's reproducible using JDK 1.3.1, not 1.3
The autoupdate types seem to be ok. Fixed because of fix of issue 11965
I don't think this is fixed. Still broken in [dev oct 30] sometimes; reinstall Ant module, Options | Building | Ant Settings looks correct and has my customized settings, but the behavior of the module is that of the default settings; from internal execution, AntSettings.getDefault().getReuseOutput() gives the default (uncustomized) value, and (AntSettings)Lookup.getDefault().lookup(AntSettings.class) throws a ClassCastException. Happens to me frequently after reinstalling Ant. Also note InstanceDataObjectModuleTest5 fails with a similar problem (class cast from lookup) though this test is using a .settings file with <module/>. A query on the old class finds the new instance.
Jesse, what you mean by reinstall ant module? As a user or by the test ant task? If the later, than this seems like the InstanceDataObjectModuleTest8... Also I am not able to see notice problem in InstanceDataObjectModuleTest5.
Reinstall with test reload task. I am going to see if the ant+apisupport module is at fault here, I think it is still using .instance but it probably can use .settings (even though the user would never customize it) just for the <module/> tag. I'm not sure if IDOMT5 failed all the time, I just noticed it failing when I wrote that message. Unfortunately it is probably timing-related.
Resolved for 3.4.x or earlier, no new info since then -> verified
Resolved for 3.4.x or earlier, no new info since then -> closing.