Community
Participate
Working Groups
I have an application using GMF that uses the ElementSelectionService to find elements in EMF models. My selection provider jobs use the EMFT Transaction API to lock the editing domain for read access. This works well as long as the dialog in which I embed the ElementSelectionComposite is not launched while the UI thread has an active transaction. When the UI thread does have a transaction (read-only or, in some cases, read-write because an AbstractEMFOperation is executing), then the selection composite never returns results because the jobs that are feeding it are blocked waiting for the editing domain lock that the UI is holding. In read-write cases, yielding does not help, because the UI thread is busily waiting for the selection jobs to finish. The current implementation of the service cannot be extended to provide the necessary transaction support. I will attach a patch that tweaks the selection service API ever so slightly, by factoring a couple of key behaviours into protected methods that an extension could override to show what is required.
Created attachment 45195 [details] Patch for selection service extensibility As promised, find attached a patch that makes the following small changes: - in ElementSelectionService and AbstractElementSelectionProvider, factors out the creation of ElementSelectionServiceJobs to allow a subclass to create a custom job implementation - in ElementSelectionService, factors out the scheduling of jobs so that a subclass can customize the scheduling of provider jobs - in ElementSelectionComposite, adds a constructor that allows clients to configure the composite with a custom selection service implementation
Committed the patch to R1_0_maintenance. I ran the JUnit tests for the element selection service and they pass. I also ran the clients application and it works as required.
[GMF Restructure] Bug 319140 : product GMF and component Runtime Common was the original product and component for this bug
