Community
Participate
Working Groups
The initialization of services in the Workbench has been reworked in in 3.6 compared with 3.5 Unfortunately source providers (initialized in Workbench.startSourceProviders()) are now initialized *after* handlers (in Workbench.initializeDefaultServices()). The result is that a handler with an activeWhen expression which refers to a source variable _other_ that the built-in variables from SourcePriorityNameMapping, will get source priority 0 - same as if it does not have an expression. Which is wrong, if the used variables have priorities installed via the extension point org.eclipse.ui.services/sourceProvider/variable. This is a blocking issues for RCP applications, as far as I can see, as later execution of the command results in no active handler! I cannot say, why the change was made between 3.5 and 3.6 - quite deliberate as seen from comments in workbench.java - so I cannot guess on a fix... -- Configuration Details -- Product: Eclipse 1.3.0.20100526-1137 (org.eclipse.epp.package.rcp.product) Installed Features: org.eclipse.platform 3.6.0.v20100527-9gF78GpqFt6trOGhCMC-p4sxjlLvz0FU_i
Created attachment 171804 [details] Sample code for problem Attached a sample RCP project that illustrates the problem with the copy command
Likely caused by bug 306736.
(In reply to comment #2) > Likely caused by bug 306736. I agree. The initialization of sources most likely should be split into two parts: - reading the services extensions - but not creating the providers themselves - very early in the initialization. Likely as in 3.5 - creating the providers themselves. Likely as in 3.6
Paul, how can you work around this problem in an application?`By setting the severity to major you essentially say, there exists a work-around for this... Or?
It represents a major loss of functionality (major). Specifically, only for handlers that are competing for the same command and their only differentiator is a user supplied variable will now conflict instead of choosing one. Normal says "some loss of functionality under specific circumstances" since it only effects certain types of handlers, which could be applied, but I think it's more serious than that. As for a workaround, there is only a programmatic one ... adding an existing variable to the activeWhen, or in your application start after you've called PlatformUI.createDisplay() but before PlatformUI.createAndRunWorkbench(*) to call org.eclipse.ui.internal.services.SourcePriorityNameMapping.addMapping(String, int). The advantage of calling SourcePriorityNameMapping.addMapping(String, int) is that in 3.6.1 it will only be filling in the values that will once again be coming from the XML. The algorithm is in org.eclipse.ui.internal.services.WorkbenchServiceRegistry.processVariables(IConfigurationElement[]), but basically it's "one greater than the provided name" for names defined in org.eclipse.ui.internal.services.WorkbenchServiceRegistry.supportedLevels I can even provide a small programmatic snippet (with on reflective call) that could be used as a workaround in your app if you think that will help. I'm going to ask around today, but I'm pretty sure that the 3.6 boat has sailed. I'll try and get a patch today, but I believe the best I can do is commit this to R3_6_maintenance so it will be in the first maintenance build. PW
I'll see if I can get the work-around to work as a fragment against Workbench 3.6.0 using the data from the extension point. Note that this problem will be seen in a very large set of RCP applications, as the common pattern here is to install a number of sources and propertyTesters to access to the global state in expressions.
Created attachment 171833 [details] WorkbenchServiceRegistry v01 Initialize the SourcePriorityNameMapping from the same place they were initialized before. PW
Created attachment 171840 [details] A fragment for 3.6.0 This is an example of using the e4-workbench.jar hook to patch the 3.6.0 workbench. I just put it in eclipse/dropins. I can provide the project zip as well, if it helps. PW
Thanks, I'll test later tonight or early tomorrow...
(In reply to comment #9) > Thanks, I'll test later tonight or early tomorrow... I was considering this for 3.6.1. Tonny, does my intended fix help in your case? PW
Boris, can I get a +1 for 3.6.1? PW
+1 from me, but it would be really good to hear from Tonny if this indeed fixes his problem.
+1 from me as well. Without the patch my tests fails on 3.6.1. With the patch, all the tests succeeds! Thanks in advance...
Released into 3.6.1 PW
