Re: [equinox-dev] Re: EclipseAppLauncher v. Declarative Services -- race

[Thomas Watson <tjwatson@xxxxxxxxxx>]

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

The ApplicationLauncher service is used
by the Eclipse Application container (implemented in org.eclipse.equinox.app)
to launch an application on the main thread.  Applications are defined
by extensions to the org.eclipse.core.runtime.applications extension point.
 When the org.eclispe.equinox.app bundle is activated it discovers
the installed applications and registers an org.osgi.service.application.ApplicationDescriptor
service for each application.  The ApplicationDescriptor services
are used to launch an application.

Applications can specify certain properties
(e.g. cardinality, thread requirements etc) see the org.eclipse.core.runtime.applications
extension point schema for more information.  If the application declares
that it must run on the main thread then when you call ApplicationDescriptor.launch
the eclipse application contain ends up calling the ApplicationLauncher
service to launch the application on the main thread.  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.

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?

Tom

"Steven E. Harris" <seh@xxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

02/27/2007 07:32 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	equinox-dev@xxxxxxxxxxx
cc
Subject	[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

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev