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.
[Nb build 200308030100, jdk1.4.2] XML actions: GenerateDTDSupport, GenerateDOMScannerSupport, etc throws: java.lang.AssertionError: Action org.openide.actions.OpenAction may not be invoked from the thread Module-Actions
Created attachment 11508 [details] AssertionError
If the stack comes from xml put it there directly next time. The error message means, the action can be invoked from AWT thread only.
I talked to Peter and he agrees that it's both: - incompatible change in actions framework - and printed assertion message is wrong Still XML module code will need to be adapted and use invokeAndWait() depending on result retrieved from asynchronous() CallableSystemAction method.
Re. incompatible change in actions framework (that actionPerformed can be called only in EQ) - yes, already noted in apichanges. Re. assertion message - what is wrong? It says OpenAction.actionPerformed may not be called from outside EQ, which is correct. GuiUtil.performDefaultAction should be changed to use invokeLater and not use ActionManager. (invokeAndWait is useless and probably unwise here.) It need not know anything about the Action in question; it must always call actionPerformed from EQ. Or the invokeLater can be skipped in case this method (GU.pDA) is itself only called from EQ, e.g. if XMLGenerateAction and its like are run directly in EQ - up to you to decide, but you must override XMLGA.asynchronous() -> false in either case.
:-) I didn't say the message is wrong.. just confusing.. it should explicitly say that the action has to be called from EQ only, what doesn't do (it just says it may not be called from the thread XXX) otherwise people keep asking what does it mean.
OK, understood, sorry - I will improve the assertion message.
Jesse commited a patch to trunk code <http://xml.netbeans.org/source/browse/xml/core/src/org/netbeans/modules/xml/core/lib/GuiUtil.java.diff?r1=1.5&r2=1.6>
Ah, yes, I had forgotten this was already filed - I just encountered it myself randomly. So the patch should have fixed the problem reported in the stack trace.
VERIFIED