Community
Participate
Working Groups
in 0315 I have an application that *had* some action delegates contributed in the plugin.xml. I changed them to all be IActions and directly contribute them to the menus. I forgot to remove the actionSet contribution in plugin.xml. When I started my application, the following was posted in the console... Could not create action delegate for id: org.eclipsercp.hyperbola.addExtensions Reason: Plug-in "org.eclipsercp.hyperbola" was unable to instantiate class "org.eclipsercp.hyperbola.update.AddExtensionsAction". Could not create action delegate for id: org.eclipsercp.hyperbola.manageExtensions There was one for each action. The failures are happening because the classes are no longer action delegates. Anyway, the failures are not interesting, the fact that someone is trying to instantiate the classes is a performance problem. Perhaps I am using an incorrect coding/contrbution pattern? Note that this was just starting the applicatoin. I did not touch anything in the UI.
Was the plug-in activated by the action set creation, or by some other means? We have logic in there to eagerly instantiate the action set delegates then a plug-in is active, but just having an action set should not cause plug-in activation.
s/then a plug-in is active/when a plug-in is active
woops, didn't mean to mark as fixed
right. the plugin was active. My impression was that the action class would not be loaded unless it was actually needed. Loading it typically will start to bring in a bunch more domain/model classes that may well not be needed until the action is run.
The reason we do it this way is that users expect more accurate enablement logic for the actions than can often be expressed in the XML declarative enablement rules when the containing plug-in is active (while users don't necessarily know about plug-in boundaries, they do know "I'm using the Java tooling, so why is this Java action enabled when it should know that it can't be run now"). This has been in here for a -long- time (I couldn't find the original PR, but see bug 6623). I would be very hesitant to remove it now.
as far as I can see, my actions do not have any enablement behaviour. They are just on.
Yes, but other actions might, and we don't know that without instantiating them <g>.
you could know if you made people tell you. Seems harsh from a performance point of view to load all classes just in case. Perhaps we can get some real numbers as to how many classes are loaded as a result of this. Is there anything in the performance infrastructure that would help?
Will look at instrumenting this early in M7.
I don't feel comfortable addressing this for 3.1. Will investigate in 3.2.
This causes *serious* pain for a large product like RAD. Many of our plugins are activated now, even when the activities they belong too are not active whatsoever. This eager plugin activation causes some popup menus to take up to 6 seconds, and completely irrelevant plugins are now activated. This takes lots of time, but what is worse, they eagerly warm up caches that never go away. Is there a workaround for Eclipse 3.0 or 3.1? Please raise the severity of this bug to 'major'.
Chris, this bug is about action set action delegates being created eagerly when the plug-in is activated. Somebody else has to have already triggered plug-in activation. See also bug 53979. But that is only for action set delegates implementing IWorkbenchWindowPulldownDelegate2. The object contributions mechanism (which appear in context menus) should not be causing early activation.
No changes planned here for 3.2. Reassigning to Doug who owns this area.
Moving Dougs bugs
Assigning to component owner PW
I think this comes down to policy. Right now, a declarative action is enabled until a user clicks on it (and it can activate the plugin). Then a common occurrence is to get a pop up: "That operation is not currently available" or something. From that point on, all actions contributed from that plugin will reflect their programmic enabled state, since they will all be loaded by our proxy actions. Commands and handlers sorta work the same way, but are more likely to write an error in the error log (which frightens people) than open the pop up. But we always get compaints about this. Either users don't like the fact that the menus are enabled when they shouldn't be or we have problems with the performance impacts of loading the delegates so that their enabled state can be correct. Commands is in slightly better shape because the interface is more restricted than actions, but it still suffers from the same question ... show the users the correct state or delay loading as much as possible until a user action. While I don't expect to actually fix this problem in 3.4 I do hope that we will pick a consistent policy and that actions and commands will follow it (as much as the platform has control over these 2 things). PW
There will clearly always be cases where we must run some Java code to determine enablement state. However, I am interested whether we can reduce this occurance significantly through the use of JavaScript to make basic state queries (by basic, I mean avoiding loading of a complex model and associated classes). ie. Is this a function of core expressions being too limited, or too hard to write? If we could reduce the occurance significantly, then the occasional "Sorry I actually couldn't perform that action" message wouldn't be too bad, given that even now there are cases where the enablement computation is too expensive to perform and must be left for command execution time. Of course, the message is less annoying if it actually contains useful information ("Sorry but you need to create a Blort first" vs. what we do now, "Sorry but we just couldn't run the action for you. Who knew?"). Agree that current approach, while providing better user experience, doesn't scale well for large products such as RAD and WID.
Yikes! Javascript! well, not yikes Javascript, yikes shipping the SDK with Rhino and having it run as part of the normal operation of the platform. While interesting I suspect that this would raise a number of issues.
(In reply to comment #17) > There will clearly always be cases where we must run some Java code to > determine enablement state. However, I am interested whether we can reduce > this occurance significantly through the use of JavaScript to make basic state > queries (by basic, I mean avoiding loading of a complex model and associated > classes). ie. Is this a function of core expressions being too limited, or too > hard to write? > Our inaccurate menu items aren't so much about core expressions (i.e. JavaScript wouldn't buy you much in this regard). Even with a core expression you can always write a test element and code whatever you want in your test(*) method. I think the number one reason we don't reflect an action state is that we haven't loaded their model. An example I see all the time: I want my connect action to be enabled when I have no connection and my disconnect action to be enabled with I have a connection ... but at the beginning they're both enabled. This bug itself is about the middle state: after the user takes one action that starts a bundle, the menus/toolbars feel free to load any action delegates (or handler implementations) for that plugin so they can programmatically update their enabled state. I have other bugs about both ends of the continuum ("My startup state is wrong" and "I didn't do anything but loaded everything"). I was just nudging this bug because I hope that in 3.4 we will have some policy that the framework will try to follow. PW
Updated as per http://wiki.eclipse.org/Platform_UI/Bug_Triage PW
Action extensions are deprecated in favor of org.eclipse.ui.commands/org.eclipse.ui.menus. No work will be planned about actions.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
