[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[equinox-dev] EclipseAppLauncher v. Declarative Services -- race condition?
- From: "Steven E. Harris" <seh@xxxxxxxxx>
- Date: Tue, 27 Feb 2007 12:38:51 -0800
- Cancel-lock: sha1:D76HwaTebITPli2AogAhD+5jbo0=
- Delivered-to: firstname.lastname@example.org
- Organization: SEH Labs
- User-agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.20 (cygwin32)
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
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)" 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.
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
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
Steven E. Harris