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: | Delete was not asynchronous: IllegalStateException at org.netbeans.modules.db.metadata.model.api.MetadataModel.runReadAction | ||
|---|---|---|---|
| Product: | platform | Reporter: | Martin Schovanek <mschovanek> |
| Component: | Actions | Assignee: | Jaroslav Tulach <jtulach> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | apireviews, jskrivanek, nleck |
| Priority: | P2 | Keywords: | API_REVIEW_FAST, REGRESSION |
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://statistics.netbeans.org/exceptions/detail.do?id=153688 | ||
| Issue Type: | DEFECT | Exception Reporter: | 153688 |
| Attachments: |
stacktrace
Almost integratable change Adjusting the patch to recent removal of context's fallback argument |
||
Created attachment 84717 [details]
stacktrace
Since build #1026 (Jul 1, 2009 2:00:37 PM) (#1025 was working correctly) from hlemyzd-2, is not possible to delete any object in DB explorer due to all destroy action are currently called in AWT but api.MetadataModel.runReadAction supposes only invocations outside AWT. It's prospective P1 problem at least in DB tooling. I plan to add another parameter to the actions to allow them to specify asynchronicity. By default off, but when specified and set to true, it would reschedule the execution to background thread, as used to be the case with original SystemActions. [JG01] Would seem simpler and clearer to me for the action to just call RequestProcessor or whatever itself; magic attributes should be avoided unless there is a definite need for them (generally in order to defer class loading). Anyway if you control the action execution directly in code, it is clearer how to run the body inside some lock, use a ProgressHandle to monitor progress, etc. Re. JG01. Your comment has been expected. You are well known for your inability to accept XYZAction.asynchronous(). Unfortunately there is no other single place to reschedule anything to RP than in Actions.callback implementation. The original DeleteAction (and co.) seeks ActionMap and then calls an action found in there on background. It seems to me that the same has to be done by its Action.callback replacement unless we want to face major incompatibilities (like this one). I don't think I followed that response. What actual change are you proposing (diff please), and what exactly is the current incompatibility? Are you proposing an asynch flag only for Actions.callback, or for all the lazy action factories? If the latter, I am opposed; if the former, I would rather suggest the option of a custom performer which would be given the real Action (ActionListener? Runnable?) and asked to somehow run it. Created attachment 85111 [details]
Almost integratable change
Diff provided. Discussion: 1. contains one failing test (marked with XXX) which shows missing implementation in already existing API. I'll deal with it meanwhile before finishing this review. 2. compatibility - I considered Jesse's "custom performer" but that is not at all necessary to fulfil the primary goal - e.g. allow new actions to behave the same way the old ones behaved. Actually it is more hurting this goal than helping to achieve it. The old actions used ActionsBridge for their background execution and the simplest way to achieve compatibility is to use ActionsBrigdge as well. 3. consistency - The expressed opinion that "for all the lazy action" is bad for "Actions.callback" is acceptable goes imho against consistency of the API, especially given the fact that callback action is in fact extension of alwaysEnabled one (can have fallback) and context actions is extension of callback (can have a key). Thus I am preferring to have consistent attribute in all of these factories. 4. XML vs. Java - right now I propose only XML API for defining asynchronous actions. If I wanted to add similar Java API compatibly, I would need to duplicate (already many argument) factory methods. That would over-complicate the API. I do not want to do that, rather I am considering to add ActionBuilder - however that is a topic for another review (not scheduled right now, but I can speed it up, if there is a preference to have it). I'd like to integrate tomorrow, then I leave for vacation and I'd like this P2 bug be fixed before that. Created attachment 85231 [details]
Adjusting the patch to recent removal of context's fallback argument
core-main#3296fc6624df Integrated into 'main-golden', will be available in build *200907281401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/3296fc6624df User: Jaroslav Tulach <jtulach@netbeans.org> Log: #168547: Support for asynchrounous declarative actions and its usage in 'delete' callback action *** Bug 168069 has been marked as a duplicate of this bug. *** |
Build: NetBeans IDE Dev (Build 200907130200) VM: Java HotSpot(TM) Client VM, 1.5.0_19-137, Java(TM) 2 Runtime Environment, Standard Edition, 1.5.0_19-b02-304 OS: Mac OS X, 10.5.7, i386 User Comments: mschovanek: Wanted to delete primary inndex at Derby DB Stacktrace: java.lang.IllegalStateException<br/> at org.netbeans.modules.db.metadata.model.api.MetadataModel.runReadAction(MetadataModel.java:87)<br/> at org.netbeans.modules.db.explorer.node.IndexNode.getTableName(IndexNode.java:207)<br/> at org.netbeans.modules.db.explorer.node.IndexNode.getTableName(IndexNode.java:132)<br/> at org.netbeans.modules.db.explorer.node.IndexNode.destroy(IndexNode.java:149)<br/> at org.openide.nodes.FilterNode.destroy(FilterNode.java:604)<br/> at org.openide.explorer.ExplorerActionsImpl$DeleteActionPerformer.doDestroy(ExplorerActionsImpl.java:658)<br/>