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.
Summary: | Unrep. NPE from PropertySheet | ||
---|---|---|---|
Product: | platform | Reporter: | Jesse Glick <jglick> |
Component: | Explorer | Assignee: | Peter Zavadsky <pzavadsky> |
Status: | RESOLVED WORKSFORME | ||
Severity: | blocker | ||
Priority: | P4 | ||
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | TASK | Exception Reporter: | |
Attachments: | Stack trace |
Description
Jesse Glick
2001-12-03 15:04:28 UTC
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] |