Sample: Starting Plugins 

Overview

By default, Eclipse plugins are lazy. Lazy is the technical term (located in the bundle's manifest) that means that plugins are started when a request is either directly made by the Platform to start the plugin or indirectly through class loading. For example, the latter case implies that when another plugin (A) instantiates a class from plugin (B), plugin (B) is started if not already. But developers may require a daemon-type plugin, one that starts and runs by itself. With such a requirement, what are the options?

Startup

Eclipse provides the org.eclipse.ui.startup extension. This allows developers to implement an interface, add the extension to their plugin, and expect the Platform to launch the plugin when the Platform starts. The startup extension loads when the user interface (PlatformUI) has loaded; consequently, developers whose code relies upon UI elements should use this pattern. Since plugins that are indirectly used by a developer's plugin could also require the UI, this is the safest method when developing plugins have dependencies on existing Expeditor plugins.

To provide an example, the OSGI Agent generally starts "some time" after the Platform has launched. Assuming the developer needs to launch the OSGI Agent as soon as possible, he or she can use the startup extension.



The extension forces the Platform to call the referenced class' earlyStartup method. Additionally, because the class has been loaded, the Activator's start method will be called as well.

Lifecycle

Expeditor provides an extension that allows developers to declare which plugins they would like to be started. The Expeditor product ensures that this controller is launched when the Platform launches and then starts the developer contributed bundles. The following contribution demonstrates how a plugin may be started when the Platform launches.



The personality ID com.ibm.rcp.platform.personality is the default personality of the Expeditor product. This causes the Expeditor framework to call the plugin's start method in the declared plugin com.ibm.rcp.support.lifecycle.extension. In other words, com.ibm.rcp.support.lifecycle.extension is our plugin that we want loaded when Platform launches.

Unlike the startup extension, the startBundles extension loads "immediately" when the Platform launches. Specifically, this occurs during the initialize and preStartup phases of the WorkbenchAdvisor. As a consequence, developers can not expect the UI to be available because the first window has yet to be opened. Developers should either use the startup pattern or write defensive code to check to ensure the PlatformUI is started.

Additionally, there is a similar extension com.ibm.rcp.lifecycle.application.startBundles that uses the application rather than personality ID.

OSGI Config

While it's beyond the scope of Expeditor, the OSGI specification defines the starting behavior of bundles. For completeness, it's worth mentioning that plugin startup may be controlled through the workspace's .config/config.ini file. This also allows developers to control the start behavior of bundles. Notice that some bundles that we expect to start earlier than others have lower start values. Bundles that do not list the start value, such as developer contributed plugins, inherit the defaultStartLevel value. It should be noted that those plugins within the default level (and any specific start level) do not have a defined ordering of starting.



Because both Expeditor and Eclipse provide mechanisms for controlling the startup of plugins, modification of the above should only be considered in rare circumstances.