The newly added framework launch in OSGi R4.2 public draft

The newly added framework launch in OSGi R4.2 public draft

This is the biggest improvement in the lifecycle layer, in the previous specification is simply described under the framework of the start and close, after the enactment of this specification, either start Equinox or Felix, can be started in the same way, in detail, this digest from the " Principles and best practices of OSGi.

Let's take a look at how an external application implements the framework's start-up through the framework's API, and look at the timing diagram of the startup method first:

This timing diagram is a complete illustration of how the framework's API can be implemented to start and stop the OSGi framework:

N Call the Newframework method of Frameworkfactory

All implementations of OSGi must implement the Frameworkfactory interface, where there is only one method, the Newframework (Map configuration), The external container has two practices in instantiating the Frameworkfactory implementation object:

A. Class.forName (Frameworkfactory implementation Class). Newinstance ()

B. Find and load the implementation class for frameworkfactory with the Serviceloader provided in Java 6, using the following method:

Assuming that com.acme.osgi.Factory is the Frameworkfactory implementation class, create a new services directory under Meta-inf and create a org.osgi.framework.launch.FrameworkFactor in this directory. Y file, the file content is: Com.acme.osgi.Factory, in the program is written to load this Frameworkfactory implementation class:

Serviceloader<frameworkfactory> sl=serviceloader.load (Frameworkfactory.class);

Iterator<frameworkfactory> It=sl.iterator ();

After creating an instance of the Frameworkfactory implementation, the Newframework method can be called, and the map parameter in the Newframework method is a configuration item that controls the behavior of the OSGi framework, with the following key:

N org.osgi.framework.bootdelegation

Configure which package needs to be loaded from boot ClassLoader, and the configured value can be com.acme.* or com.acme.services.

N org.osgi.framework.executionenvironment

Configure the environment that is required for the framework execution, such as j2se-1.5.

N org.osgi.framework.library.extensions

Native code extension configuration, such as So,dll.

N Org.osgi.framework.startlevel

Configure the bundle start level.

N Org.osgi.framework.storage

Configure the path to store information such as the bundle state of the OSGi application runtime, and when this path does not exist, the framework is responsible for creating it, and throws an exception if creation fails.

N Org.osgi.framework.storage.clean

Configuring whether the storage directory is to be purged, such as a value configured as Onfirstinit, means that the storage directory will be emptied before the framework bundle is initialized for the first time, The benefit of this configuration item is that it is possible to control whether the framework restarts after the start of the last runtime state.

N org.osgi.framework.system.packages

The parent classloader of the framework should export the packages to the outside.

N Org.osgi.framework.system.packages.extra

The configuration of the extended properties is added based on the above configuration items, for example:

org.osgi.framework.system.packages.extra=org.acme.foo;version=1.2

N org.osgi.framework.bundle.parent

As with the Osgi.parentclassloader attribute in Equinox, it is used to control which classloader the boot ClassLoader is, with four optional attribute values: Boot, App, ext, framework, The meaning is exactly the same as equinox.

Once you have configured the appropriate values for these properties, you can call the Newframework method to create the framework object.

N Call the framework's Init method

The creation of the bundle context and the injection of the framework services are done in the Init method.

n Get bundlecontext through the framework

N Installation Bundle

Install the required bundles via bundlecontext.installbundle.

N Call the framework's Start method

The framework sets the Startlevel service to the specified boot level, thereby promoting the resolve and startup of all bundles that have been installed.

N Call the Waitforstop method of the framework

Call this method to wait for the framework to stop running.

As described above, a typical example of the startup process code for the OSGi framework based on the OSGi R4.2 specification is as follows:

Map p=new HashMap ();

P.put ("Org.osgi.framework.storage", System.getproperties ("User.home") +file.separator+ "OSGi");

Frameworkfactory factory=class.forname (factoryclassname). newinstance ();

Framework framework=factory.newframework (P);

Framework.init ();

Bundlecontext Context=framework.getbundlecontext ();

...//install bundles

Framework.start ();

Framework.waitforstop ();

Compare Felix's startup code, does it feel a bit similar?

The lifecycle of the framework is also described in detail in the OSGi specification, as shown below:

See what happens with init, start, and the stop framework.

N Init

After Init, the following effects are required:

Start the event distribution processing function;

Configure security Manager;

The Startlevel is set to the specified Startlevel, which defaults to 0;

Create an available Bundlecontext object;

The status of all installed bundles is set to installed;

Services provided by the framework are available;

The state of the framework is starting.

N Start

Responsible for starting the corresponding installed bundle according to Startlevel, if the bundle fails to start, the broadcast Framework.error event, after the completion of the framework status of active.

N Stop

Responsible for stopping all running bundles, releasing all resources, and placing the framework's status as resolved.

N Update

Stop the framework and return the Stopped_update or Stopped_bootclasspath_modified event value to the Framework.waitforstop method, and the app code should do its own update processing.

In the framework specification, OSGi also illustrates that the framework runs in multithreaded mode, that is, all bundles run in their own threads and are based on event mechanisms to respond to events from other bundles. From the above changes, the additional framework chapters are the biggest changes, and the framework specification draws on the advantages of Felix and Equinox, which will play a significant role in unifying the start-up and behavior of the OSGi framework, especially for embedded OSGi The application of the framework and the OSGI applications that need to be integrated with other containers will be of great help.