[
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:
http://www2.osgi.org/JSR232/Spec
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
