Bug 168547 - Delete was not asynchronous: IllegalStateException at org.netbeans.modules.db.metadata.model.api.MetadataModel.runReadAction
Delete was not asynchronous: IllegalStateException at org.netbeans.modules.db...
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Actions
6.x
All All
: P2 (vote)
: 6.x
Assigned To: Jaroslav Tulach
issues@platform
http://statistics.netbeans.org/except...
EXCEPTIONS_REPORT
: API_REVIEW_FAST, REGRESSION
: 168069 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-14 14:39 UTC by Martin Schovanek
Modified: 2010-01-18 07:34 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
stacktrace (2.93 KB, text/plain)
2009-07-14 14:39 UTC, Martin Schovanek
Details
Almost integratable change (23.43 KB, image/png)
2009-07-23 10:07 UTC, Jaroslav Tulach
Details
Adjusting the patch to recent removal of context's fallback argument (24.07 KB, patch)
2009-07-27 08:38 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Schovanek 2009-07-14 14:39:30 UTC
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/>
Comment 1 Martin Schovanek 2009-07-14 14:39:35 UTC
Created attachment 84717 [details]
stacktrace
Comment 2 Jiri Rechtacek 2009-07-15 16:05:09 UTC
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.
Comment 3 Jaroslav Tulach 2009-07-22 15:06:36 UTC
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.
Comment 4 Jesse Glick 2009-07-22 15:13:27 UTC
[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.
Comment 5 Jaroslav Tulach 2009-07-22 15:50:39 UTC
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).
Comment 6 Jesse Glick 2009-07-22 16:22:06 UTC
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.
Comment 7 Jaroslav Tulach 2009-07-23 10:07:31 UTC
Created attachment 85111 [details]
Almost integratable change
Comment 8 Jaroslav Tulach 2009-07-23 10:31:42 UTC
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).

Comment 9 Jaroslav Tulach 2009-07-26 09:00:27 UTC
I'd like to integrate tomorrow, then I leave for vacation and I'd like this P2 bug be fixed before that.
Comment 10 Jaroslav Tulach 2009-07-27 08:38:05 UTC
Created attachment 85231 [details]
Adjusting the patch to recent removal of context's fallback argument
Comment 11 Jaroslav Tulach 2009-07-27 20:46:48 UTC
core-main#3296fc6624df
Comment 12 Quality Engineering 2009-07-28 17:47:44 UTC
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
Comment 13 Jaroslav Tulach 2010-01-18 07:34:56 UTC
*** Bug 168069 has been marked as a duplicate of this bug. ***


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo