[equinox-dev] EclipseAppLauncher v. Declarative Services -- race conditi

["Steven E. Harris" <seh@xxxxxxxxx>]

I've had a skeletal application working for a while here that started
as follows. One of my bundles that I call the "root bundle" has a
class (we'll call it "RootImpl" here) that implements the
org.eclipse.osgi.service.runnable.ApplicationRunnable interface.

In the root bundle's activator, it would create an instance of
RootImpl and register it as a o.e.o.s.r.ParamaterizedRunnable service
with a property "eclipse.application" set to true. This service would
be picked up by org.eclipse.osgi.service.runnable.EclipseAppLauncher
in its findRunnableService() method, and eventually be called upon to
"start" in EclipseStarter.run().

This was all working fine until I tried to convert the "root bundle"
to use Declarative Services. It seems that there's a race condition
(or some other problem with similar effects) between
EclipseAppLauncher.findRunnableService() looking for a registered
ParamaterizedRunnable service and my "root bundle" getting registered
as such a service by DS.

DS does eventually register the ParamaterizedRunnable service, but
findRunnableService seems to catch DS in various states. Sometimes the
call to "context.getServiceReferences()" on line 48 in
EclipseAppLauncher doesn't see any registered ParamaterizedRunnable
services. Most of the time it does see one registered service, but the
call "context.getService(runRefs[0])" on line 54 returns null.

If I put a breakpoint at line 54 to slow things down, the
"context.getService()" call will usually return a reference to my
ParamaterizedRunnable service. Without the breakpoint, it seems that
things happen too quickly, and DS doesn't finish setting up the
service until after EclispeAppLauncher has checked for it.

Now, I did figure this out: DS creates a file called "cdcache.ser" in
its "org.eclispe.osgi/bundles/<bundle ID>/data" directory. If I delete
this file before starting the program again, the service discovery
works fine on the next run, irrespective of timing interaction.

Three questions:

o Is there anything I should try to speed up DS or slow down the
  Equinox start-up sequence? Maybe try forcing my component to be
  "immediate"?

o Should DS work with the "cdcache.ser" file left from a previous run?

o There are several comments in EclipseAppLaucher about backward
  compatibility with 3.0, 3.1, and 3.2. Is this registration of a
  ParamaterizedRunnable no longer the "blessed" way to have Equinox
  start up an "application"? Is there some other mechanism I should be
  using?

-- 
Steven E. Harris