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.
Observed in [r33 dec 03]. What is weird about it: activeNode.getCustomizer() is null (why? why is it being customized if it has none? probably a race condition); and this section of code is not even supposed to be run except in standalone mode. Seen in a fresh build with one module (ant) while playing with showing and closing dialogs (Filesystems customizer specifically). Could prevent by just returning if aN.customizer==null, but clearly something else was wrong.
Created attachment 3675 [details] Stack trace
Eval: I don't see a synch problem there. The setting of activeNode(AN) and enabling/disabling of the customizer button is done in one task always done in AWT thread. Then invoking of the customizer is also done always in AWT. So I only suspect the AN which claimed it has a customizer (hasCustomizer == true), returned null from getCustomizer method. (Don't you remember the node which you tried to customize?)
As I wrote, I think the node in question was the Filesystems root node, which should of course always have a customizer.
Hm, the FileSystems node is OK. I looked again at it and didn't find something suspicious. Really very strange, why it has passed to the wrong code section and why it was null. It makes me to worry if we patch it the way just to return on null customizer, we never find the cause of the problem. So I would rather suggest to throw IllegalStateExc with the node which had null customizer instead.
Right. I guess this can be closed as WORKSFORME, it is clearly unreproducible. Maybe more information will appear later.
Closing as worksforme. Also added to the code to throw IAE when the node doesn't have customizer with the node in message. Change: openide/../explorer/propertysheet/PropertySheet.java [1.76]