OSGI life cycle

1 life cycle management for non-modular applications, the lifecycle ApplicationAs a whole, and for modular applications, you can Fine Grain sizeThe way to manage an individual part of the application. OSGi Life Cycle Management

The OSGi life cycle layer has two different roles:

• Outside of the application, the related operations on the bundle lifecycle are defined. The OSGi lifecycle layer allows you to customize the configuration of your application by installing, starting, updating, stopping, and uninstalling different bundles from the outside at execution time.
• Inside the application, the way the bundle accesses its execution context is defined, providing a way for the bundle to interact with the OSGi framework, as well as some convenient conditions for execution.

Standard Java life cycle management Installation:Jar is installed when downloading; Execution: Executed when the user starts the JVM; (Double-click) Update: Replace jar file; To Remove:Delete the jar file. Servlet Life Cycle Management

Lifecycle is managed by the servlet container

Installation:A specific process is installed through the container; Execution:The Servlet container invokes various life cycle APIs, such as Servlet.init (), Servlet.destroy (); Update: Replace the war file; removed from: A specific process is removed through the container. 2 life cycle Layer Three interfaces Bundleactivator if you want to manage a bundle in a lifecycle, you must declare a Bundle Activatorclass to implement the Org.osgi.framework.BundleActivator interface. This interface provides the bundle with hooks to the life cycle layer, while customizing the actions that the bundle performs when it starts or stops.

must also be in MANIFEST. The bundle activator is described in MF:

Bundle-activator:org.alpha.myactivatorNote: Not all bundles require an activator. The activator must be required only if you explicitly need to interact with the OSGi API, or if you need to perform a custom initialization/destroy action.

• When the bundle is installed and started, the framework constructs an instance of the corresponding bundleactivator, triggering the bundleactivator. start ();
• When the bundle is stopped, the framework calls Bundleactivator. stop (); the Stop () method should cancel all operations performed in Start ().

Public InterfaceBundleactivator {
Public voidStart (Bundlecontext context) throwsException;
Public voidStop (Bundlecontext context) throwsException;
}

Bundlecontext

All two methods of Bundleactivator accept a Bundlecontext object as a parameter. Bundlecontext is a bridge between bundle and OSGi framework communication. The things bundlecontext can do are:

• Look up system-wide configuration properties;
  --Get System Properties
• Find another installed bundle by its ID;
  --querying additional bundles that have been installed by ID
• Obtain a list of all installed bundles;
  --Get a list of installed bundles
• Introspect and manipulate other bundles programmatically:start them, stop them, un-install them, update them, etc;
  --operation of other bundles in the program (Start, Stop, uninstall, update)
• Install new Bundles programmatically;
  --Install new bundles in the program
• Store or retrieve a file in a persistent storage area managed by the framework;
  --store or query files in a persisted storage area managed by the framework
• Register and unregister bundle listeners, which tell us when the state of any bundle in the framework changes;
  --Register bundle Listener, monitor the change of bundle status
• Register and unregister service listeners, which tell us if the state of any service in the framework changes
  --Register Service Listener, monitor service status changes
• Register and unregister framework listeners, which tell us about the general framework events.
  --Register the Framework Listener, monitor general framework events

Each activated bundle receives its own Bundlecontext object, which cannot be passed directly to the bundle!

The Bundlecontext object is valid only if the bundle is active (starting at Start () and ending with Stop (). An exception is thrown when the object is called in other states.

Public InterfaceBundlecontext {
String GetProperty (string key);
Bundle Getbundle ();
Bundle Getbundle ( LongID);
Bundle[] Getbundles ();

Bundle Installbundle (String location) throwsBundleexception;
Bundle Installbundle (String location, InputStream input) throwsBundleexception;

voidAddbundlelistener (Bundlelistener listener);
voidRemovebundlelistener (Bundlelistener listener);
voidAddframeworklistener (Frameworklistener listener);
voidRemoveframeworklistener (Frameworklistener listener);
}

Bundle

For each bundle that has been installed, the framework creates a bundle object that logically represents him. The bundle interface defines a series of APIs to manage the lifecycle of installed bundles.

Public InterfaceBundle {
Bundlecontext Getbundlecontext ();
LongGetbundleid ();
Dictionary getheaders ();
intGetState ();
String Getsymbolicname ();
Version getversion ();

voidStart intOptions throwsBundleexception;
voidStart () throwsBundleexception;
voidStop intOptions throwsBundleexception;
voidStop () throwsBundleexception;
voidUpdate (InputStream input) throwsBundleexception;
voidUpdate () throwsBundleexception;
voidUninstall () throwsBundleexception;
}
Note: The bundleid=0 bundle represents the OSGi framework itself, called System Bundle。
When the system bundle is stopped, it stops the other bundles first, then shuts itself down completely, and closes the frame in a friendly manner. 3 Life cycle Status

Installed

When Bundlecontext.installbundle () is called, a bundle of installed states is created

Resolved

If all the bundles on which it relies are present, that is, the parse succeeds, go to the resolved state

Note: Not directly from installed--starting

Starting

When the execution of Bundleactivator.start () is started, it is in the starting state;

Note: This is a transient state

ACTIVE

When execution Bundleactivator.start () succeeds, it goes to the active state;

If an exception is thrown, return to the resolved state.

Stopping

When the execution of Bundleactivator.stop () is started, it is in the stopping State;

If the execution succeeds, go to the resolved state. Note: This is a transient state uninstalled

Bundles of the installed state can be unloaded and transferred to the uninstalled State;

If you unload an active state bundle, the framework first automatically stops the bundle to go to the resolved state, and then, before uninstalling, turns its state to installed.

Although the uninstalled state was shown here, we can never see a bundle in that state, and an uninstalled bundle Cannottra Nsition to any other state. Even if we reinstall the same bundle JAR file, it'll be considered a different bundle by the framework, and assigned a n EW bundle ID. Refresh/Update

Refreshing or updating a bundle will return its status to the installed state!

OSGI life cycle