1

I have an RCP 3.7 application that requires two database connections, the code for each database is in a separate bundle. Previously the database startup was done in the Activator.start() methods. I have heavily refactored the code to move the database startup into two Declarative Services. This achieved the goal of breaking the tight coupling and excessive package exposure across bundles (almost everything was exported).

The challenge I have now is that the two Services do not start quickly enough, the workbench loads and I'm getting thread violations. I have both services set immediate=true. The bundle start order is eclipse.osgi at -1 (default), equinox.ds and equinox.common at 2, core.runtime at default. I have tried adding start levels for my bundles but it did not help so removed them.

Any thoughts or suggestions on how to ensure the database starts before the service returns?

Timothy Vogel
  • 1,363
  • 2
  • 21
  • 39
  • Have you tried setting `Bundle-ActivationPolicy: lazy` in the manifest? Take a look at [this post](http://stackoverflow.com/a/17592449/1288408) for using lazy bundle activation with Declarative Services. – Modus Tollens Aug 01 '14 at 07:53
  • Thanks for the suggestion. I already have that option set to lazy. Great link as I now know WHY it is set! – Timothy Vogel Aug 01 '14 at 11:12

1 Answers1

3

It looks like you are accessing SWT from within the DS activation thread. Please use Display.asyncExec to access SWT code from other threads. See PlatformUI.getWorkbench for accessing the Display.

Gunnar
  • 2,264
  • 17
  • 31
  • Impressive! I don't know how you went from DS to SWT but you were right. I changed Display.getDefault().getSystemCursor(SWT.CURSOR_WAIT) to PlatformUI.getWorkbench().getDisplay().getSystemCursor(SWT.CURSOR_WAIT) and the problem was corrected! – Timothy Vogel Aug 01 '14 at 14:41
  • It's 'Eclipse RCP' and 'thread violations' which led me there. Anyway, you should probably wrap the code into a PlatformUI.getWorkbench().getDisplay().asyncExec(new Runnable...) to in order to ensure that it's running on the UI thread *and* not blocking the current thread. However, this also depends heavily on what you are doing with the color. You should not block the UI thread either with too expensive operations. – Gunnar Aug 02 '14 at 01:56