Skip to main content

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

"Steven E. Harris" <seh@xxxxxxxxx> writes:

> 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?

I figured out another approach that solves my initialization timing
problem, though I'm still not sure it's the blessed way.

Rather than registering my ParamaterizedRunnable as a service, I look
for the registered ApplicationLauncher when my "root" bundle gets
activated, and call on ApplicationLauncher.launch(), providing "this"
as the ParamaterizedRunnable instance:

,----[ My "root bundle" activate() method ]
| protected void activate(org.osgi.service.component.ComponentContext ctx) {
|    //...
|    final org.eclipse.osgi.service.runnable.ApplicationLauncher launcher =
|          (org.eclipse.osgi.service.runnable.ApplicationLauncher) ctx.locateService( "LAUNCHER" );
|    if ( null != launcher)
|       // TODO: Consider using inner class to implement ApplicationRunnable instead.
|       launcher.launch( this, null );
|    else
|       // TODO: Log an error here, though this should not happen,
|       //       as "LAUNCHER" is a mandatory reference.
|       ;
| }
`----

I found that I have to set the eclipse.application.launchDefault
property to false in order to force the main thread to wait in
EclipseAppLauncher.start() for my "root bundle" to call launch().

Well, that took most of the day to figure out. Is this system
documented somewhere?

-- 
Steven E. Harris



Back to the top