[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Re: EclipseAppLauncher v. Declarative Services -- race condition?

You can obtain the specification from here:


Kind regards,

     Peter Kriens
SEH> Thomas Watson <tjwatson@xxxxxxxxxx> writes:

>> Sorry for the late response.  This mail got buried in the midst of
>> EclipseCon week.  Just catching up.

SEH> No problem. I appreciate the input, no matter when.

SEH> [...]

>> When the org.eclispe.equinox.app bundle is activated

SEH> Well, keep in mind that I'm only using Equinox as it's packaged in the
SEH> org.eclipse.osgi bundle/JAR, which does not include anything in the
SEH> org.eclipse.equinox.app package. Which bundles would I need to take
SEH> advantage of the org.eclispe.equinox.app package?

>> it discovers the installed applications and registers an
>> org.osgi.service.application.ApplicationDescriptor service for each
>> application.

SEH> I don't see this package in the Compendium documentation, so I guess
SEH> it must be a later addition? Looking around now I found the Javadoc
SEH> and source in the Equinox CVS repository. This is some new material to
SEH> study.

>> The ApplicationLauncher service should not be used by clients, it is
>> meant to be used the eclipse application container.  Up to this
>> point the ApplicationLauncher service has been considered internal
>> API between the launcher which is in control of the main thread and
>> the Eclipse application container.

SEH> My goal was to stop EclipseAppLauncher.start() from throwing an
SEH> exception when called upon by EclipseStarter.run(), and in
SEH> investigating that I saw that there was an interaction between Equinox
SEH> registering an ApplicationLauncher and optionally it looking for a
SEH> registered ParamaterizedRunnable to use as the "default
SEH> application". Using either approach works, but apparently I'm digging
SEH> into depths I shouldn't be.

>> I'm not sure why you are needing to call this method to solve a
>> timing issue.  Do you need your application to be launched later
>> after some other operation has occurred?

SEH> As EclipseAppLauncher and EclipseStarter are written, after the
SEH> framework has started and loaded its initial bundles, one of two
SEH> things must have occurred in order for an "application" (given my
SEH> limited view) to be started: Either a ParamaterizedRunnable must have
SEH> been registered by a bundle, or one of the bundles must have found a
SEH> registered ApplicationLauncher and called its launch() method.

SEH> If some of these initial bundles are assisted by Declarative Services
SEH> (or iPOJO, or Spring OSGi), their "boot up" may happen asynchronously
SEH> to the bundles having started, so that by the time they register a
SEH> ParamaterizedRunnable or find a registered ApplicationLauncher (on a
SEH> separate thread), EclipseAppLauncher.start() has already been called
SEH> by EclipseStarter.run().

SEH> The only way out of this race condition is to set the
SEH> eclipse.application.launchDefault property to false¹, which will force
SEH> EclipseAppLauncher.start() to wait until ApplicationLauncher.launch()
SEH> gets called on eventually, providing EclipseAppLauncher the
SEH> ParamaterizedRunnable it needs to run as "the application".

SEH> Speaking more broadly, I came to Equinox testing whether I could use
SEH> it as an alternative to Felix, embedded in my larger application. I'm
SEH> not looking to create an "Eclipse application", so I've been trying to
SEH> bite off the smallest possible parts of Equinox while still using it
SEH> as intended. Would you still advocate me pursuing the
SEH> org.eclipse.core.runtime.applications extension point idea you
SEH> sketched?

SEH> Footnotes: 
SEH> ¹ It is treated as true by default on line 347 in EclipseStarter.java.

Peter Kriens                              Tel +33467542167
9C, Avenue St. Drézéry                    AOL,Yahoo: pkriens
34160 Beaulieu, France                    ICQ 255570717
Skype pkriens                             Fax +1 8153772599