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.
Build: NetBeans IDE Dev (Build 20080919181052) VM: Java HotSpot(TM) Client VM, 11.0-b11, Java(TM) SE Runtime Environment, 1.6.0_10-beta-b14 OS: Linux, 2.6.24-19-generic, i386 Stacktrace: java.lang.reflect.UndeclaredThrowableException at $Proxy.resultChanged(.java:0) at org.openide.util.lookup.ProxyLookup$1Notify.run(ProxyLookup.java:173) at org.openide.util.lookup.ProxyLookup.setLookups(ProxyLookup.java:179) at org.openide.util.lookup.ProxyLookup.setLookups(ProxyLookup.java:119) at org.openide.explorer.DefaultEMLookup.updateLookups(DefaultEMLookup.java:131) at org.openide.explorer.DefaultEMLookup.propertyChange(DefaultEMLookup.java:163)
Created attachment 70439 [details] stacktrace
Looks like this is not so common error to desperately require P3 priority.
The faulty call originates at org.netbeans.modules.apisupport.beanbrowser.LookupNode$1Proxy.resultChanged(LookupNode.java:492)
No idea what is wrong with the code: private static Lookup ignoreBbNodes(final Lookup orig) { class Proxy extends AbstractLookup implements LookupListener { private final InstanceContent content; private Collection copy = Collections.EMPTY_SET; private final Lookup.Result master = orig.lookup(new Lookup.Template(Object.class)); public Proxy() { this(new InstanceContent()); } private Proxy(InstanceContent content) { super(content); this.content = content; Lookup.Result r = orig.lookup(new Lookup.Template(Node.class)); r.addLookupListener((LookupListener) WeakListeners.create(LookupListener.class, this, r)); resultChanged(null); } public void resultChanged(LookupEvent ignore) { if (!containsBbNode(orig)) { copy = master.allInstances(); } content.set(copy, null); } } return new Proxy(); } Clearly the InstanceContent is being used in exactly one AbstractLookup - the containing Proxy. So the error message "You cannot use ... in more than one AbstractLookup" sounds like a bug in AbstractLookup to me, unless it is referring to something other than what it seems to be referring to.
The code looks OK. Can it really generate the exception?
Apparently so. Note that despite the report date, based on line numbers in the stack trace the code seems to be coming from sometime between Jun 30 2006 and Sep 26 2007. Nonetheless, the ignoreBbNodes method has not changed since that time.
Only one report ever.