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.
I found it with latest release33 build but I suppose it is not specific. (XML module is build from main trunk). Steps to reproduce: 1.XML module must be installed/enabled. 2.Open any DTD in editor. It uses text editor component from XML module. 3.Disable whole XML module. NoClassDefFounds exception is displayed in dialog.
Created attachment 4373 [details] exception.html
Are you able to reproduce it? I am not. Please, try XML module from release33 branch. And if you find steps to reproduce, please reopen this.
I checked with XML module from release33 branch and it is the same. I am sorry I forgot one step (now it seems it is important) - between steps 2 and 3 you must restart IDE. I attach dump stack from release33 module.
Created attachment 4380 [details] exception33.html
It looks like modules are not uninstalled in rigth order. TAX (cointains class org.netbeans.tax.TreeDocumentRoot) is autoload module and it looks, it is uninstalled before XML Core module (org.netbeans.modules.xml.core.sync.DataObjectSyncSupport), although XML Core depends on TAX.
The modules are uninstalled in the correct order. The problem is that the file is closed long after they are all gone. And the XML module includes complex closing hooks - meaning that it is running all sorts of code after it has been uninstalled as far as the IDE goes. The problem is the IDE's threading model, if you can call it that - it fires loader pool changes asynchronously (and after a delay for that matter), and the modules are gone well before the editor support receives a message telling it to close itself. I can easily work around the NoClassDefFoundError. But that will just leave the possibility of equally serious, but harder to see and find, bugs, since the XML module may still be doing whatever sorts of things (accessing settings, ...) when all of its supporting infrastructure has already disappeared. One workaround inside the XML module itself is to keep a global flag in the ModuleInstall so it knows when it is uninstalled. If that flag is set, various hooks and listeners should deactivate themselves and exit early. Ugly but it will help.
Created attachment 4396 [details] Log file displaying the timing issue in XML module code + loader pool + editor support
Created attachment 4397 [details] Workaround patch
The patch below will suppress the NCDFE and cause the pane to close quietly (I tried with [dev jan 22]). It permits classes from disabled modules to still be loaded and used in (obsolete) child classloaders. This makes it possible for modules to not implement the workaround I suggested (keeping track of when they are disabled and stopping all activity at that time). I don't really like the patch much however and I am not in favor of applying it to the core, especially on a tight time frame. For one thing, it does not warn about classes loaded *within* obsolete classloaders. It could have the effect of making other such bugs simply more difficult to find, without actually curing the evil symptoms. Perhaps a modified patch which makes the destroy() method only warn about all subsequent loads would be better. That would have the advantage of only logging warnings to the log file for developers, while catching enough problem situations to convince module developers to implement the shutdown logic I suggest. The ideal situation would be a sane threading model in which everything related to a module's state would be handled synchronously. But this would require a rewrite of much of the IDE. Don't expect it anytime soon.
Created attachment 4399 [details] Better patch; logs warnings for illegal uses
Adding Petr N. to CC, he is a co-author of the affected class.
Applying the patch to the trunk. However it seems there is a *lot* of code from various places that can be run in dead classloaders, showing an interesting variety of threading bugs in the IDE. We may be able to fix some of them in the 3.4 dev cycle. I would not recommend this patch for 3.3.1 particularly - if people uninstall modules frequently, especially while doing things with the modules right beforehand, there are likely to be a lot of exceptions going into their logfiles. Not visible unless they look in the logfile, of course, but still a lot of "noise" that may alarm users unnecessarily. Only advisable IMHO if the root problem cannot be fixed in the XML module easily, cf. issue #19743. Might be 3.3.1_WAIVER, will wait for some second opinions and news from XML developers. committed Up-To-Date 1.7 core/src/org/netbeans/core/modules/ProxyClassLoader.java
Created attachment 4647 [details] Yet another patch; logs which class was being loaded too
It seems there is an unrelated but serious VM error in 1.4 which appears to be worked around by this patch.
Cf. BugTraq #4623152.
We have tested the 2/11 patch with NB 3.3.1 and internal FFJ builds and it found it to be a reliable workaround for the 1.4 HotSpot bug #4623152.
*** Issue 21530 has been marked as a duplicate of this issue. ***
Petr - please take a look at the last diff if you have not already, just to make sure you see nothing wrong. Thanks.
I've already looked at it. It seems OK to me.
Tested this patch with Forte and Verifying. Also seen mentioned exception in the ide.log. Will mark as verified after integration into 3.3.2.
x
Assigning to Petr for physical integration - thanks.
Integrated into orion_fcs branch
Verified in FFJ40. Again one informational exception in ide.log after disabling jpda debugger and all depending modules.
Resolved for 3.4.x or earlier, no new info since then -> closing.