Page Comparison

...

An OSGi bundle can be in one of the following states:

Property	Purpose
`Installed`	The bundle has been successfully installed.
`Resolved`	All Java classes that the bundle needs are available. This state indicates that the bundle is either ready to be started or has stopped.
`Starting`	The bundle is being started, the `BundleActivator`.start method has been called, but the start method has not yet returned.
`Active`	The bundle has successfully started and is running.
`Stopping`	The bundle is being stopped. The `BundleActivator`.stop method has been called but the stop method has not yet returned.
`Uninstalled`	The bundle has been uninstalled. It cannot move into any other state.

OSGi Bundle Lifecycle

The lifecycle of an OSGi bundle is depicted in the figure below. The lifecycle starts with the installation of the bundle. If all Java classes that the bundle depends on are available, the OSGi bundle proceeds to the resolved state. From there the bundle can be started or uninstalled. When started, the bundle becomes active unless some runtime error occurs during the starting of the bundle. If that happens, the bundle remains resolved. An active bundle can be stopped in which case the bundle proceeds to the resolved state. When a resolved bundle is uninstalled it proceeds to the uninstalled state and stays there.

...

A plugin exists only within the active state of the OSGi bundle, therefore the API that makes an OSGi bundle a plugin can only be accessed during the active state of the OSGi bundle. The API methods of a plugin that affect the lifecycle of the plugin are available on a component bundle, which is only available when the bundle is active. These methods are:

Property Purpose

Start()

Registers services that each component within the bundle exposes if all required service dependencies are available. For each component, at least a component service is registered.

Stop()

Stops all services registered by the component.

Update()

Updates a plugin to a new version.

Uninstall()

Removes all content that was created during the installation of the component and uninstalls the plugin.

Uninstall(doPurge)

Removes all content that was created during and after the installation of the component and uninstalls the plugin.

Note
A plugin must be in an active state before you can uninstall it. If a plugin has dependencies with another plugin, you must first uninstall the dependent plugin(s).

Purge()

The bundle has been uninstalled. It cannot move into any other state.

The lifecycle of a plugin is depicted below.

...

The plugin lifecycle methods are:

Lifecycle Purpose

onStart()

Allows a component to attach logic to a start event. For example:

Code Block

theme	Eclipse

public void onStart() {
   LOG.log(Level.INFO, “onStart() invoked!");
}

Dependencies: onStart() is invoked after onInit() and before onInstall() and onUpdate(), therefore onStart() should not depend on logic contained within onInstall() and onUpdate():

onInit()

onStart()

onInstall()

-----------

onInit()

onStart()

onUpdate()

onInstall()

Allows a component to attach logic to an install event. For example:

Code Block

theme	Eclipse

public void onInstall() {
   LOG.log(Level.INFO, “onInstall() invoked!");
}

Dependencies: onInstall() is invoked after onInit() and onStart():

onInit()

onStart()

onInstall()

onStop()

Allows a component to attach logic to a stop event. For example:

Code Block

theme	Eclipse

public void onStop() {
   LOG.log(Level.INFO, “onStop() invoked!");
}

Dependencies: onStop() is invoked before onDestroy(), therefore it should not depend on logic contained within onDestroy():

onStop()

onDestroy()

onUpdate()

Allows a component to attach logic to an update event. For example:

Code Block

theme	Eclipse

public void onUpdate() {
   LOG.log(Level.INFO, “onUpdate() invoked!");
}

Dependencies: onUpdate() is invoked after onInit() and onStart():

onInit()

onStart()

onUpdate()

onUninstall()

Allows a component to attach logic to an uninstall event. The plugin containing the component must be in an active state in order for the onUninstall() method to be invoked. For example:

Code Block

theme	Eclipse

public void onUninstall() {
   LOG.log(Level.INFO, “onUninstall() invoked!");
}

Dependencies: onUninstall() is invoked before onStop() and onDestroy(), therefore it should not depend on logic contained within onStop() and onDestroy():

onUninstall()

onStop()

onDestroy()

onPurge()

Allows a component to attach logic to a purge event.

Note
The plugin containing the component must be in an active state in order for the `onPurge()` method to be invoked.

Code Block

theme	Eclipse

public void onPurge() {
   LOG.log(Level.INFO, “onPurge() invoked!");
}

Dependencies: onPurge() has no dependencies.

onInit()

Allows a component to attach logic to an init event. For example:

Code Block

theme	Eclipse

public void onInit() {
   LOG.log(Level.INFO, “onInit() invoked!");
}

Dependencies: onInit() is always invoked first, therefore it should not depend on logic from any other method.

onDestroy()

Allows a component to attach logic to a destroy event. For example:

Code Block

theme	Eclipse

public void onDestroy() {
   LOG.log(Level.INFO, “onDestroy() invoked!");
}

Dependencies: onDestroy() has no dependencies:

onStop()

onDestroy()

Back to Top

...

Plugin Management Console

...

In addition to the functionality available for managing plugins from the XperienCentral Plugins Management Console, there are equivalent commands available in the Apache Felix Gogo shell that you can invoke directly from the command line. To use the commands on a plugin in the Apache Felix Gogo shell, you must determine the ID of a plugin by issuing the ps command. After you issue the ps command, you will see a list of the plugins as shown in the figure above.

Command Purpose

wmstart [id]

Registers services that each component within the bundle exposes if all required service dependencies are available. For each component, at the very least a component service is registered

wmstop [id]

Stops all services registered by the component.

wmupdate [id]

Updates the plugin to a newer version. If a problem is encountered during the update, the plugin is automatically rolled back to the existing version. The following describes a typical plugin update scenario:

The plugin developer creates a 1.1 version of a plugin and gives it to a system administrator.
The system administrator copies the updated plugin to the machine running XperienCentral. If XperienCentral is running in a clustered environment, the updated plugin is copied to the machine running the master XperienCentral instance.
The system administrator determines the ID of the plugin in the Apache Felix Gogo shell.
The system administrator executes the wmupdate method, specifying the ID of the plugin to update and the absolute path of the JAR file containing the updated plugin. For example:wmupdate 59 file:/home/deploy/helloworld_1_1.jar
The plugin is updated to the new version and is set to the active state. In a clustered environment, the plugin is also automatically updated on all slave instances.

wmpurge [id]

Removes all content that was created during and after the installation of the component.

wmuninstall [id]

Removes all content that was created during the installation of the component.

Note
A plugin must be in the active state before you can uninstall it. If a plugin has dependencies with another plugin, you must first uninstall the dependent plugin. A plugin must be in the active state before you can purge it.

Back to Top

...

Service Dependencies

...

The table below shows an overview on the service injections for each component type.

Component	Service is injected in	Injection type
Element	`SimpleElementComponent`	Field access
Element	`ElementBase`	Setter method
Panel	`SimplePanelComponent`	Field access
Panel	`PanelBase`	Setter method
Media item	`SimpleMediaItemComponent`	Field access
Media item	`MediaItemArticleVersionImpl`	Setter method
Form	`SimpleFormComponent`	Field access
Form	`FormHandlerBase`	Setter method
Page metadata	`SimpleMetaDataComponent`	Field access
Page metadata	`PageMetaDataBase`	Setter method
Presentation	`SimplePresentationComponent`	Field access
Service	`SimpleServiceComponent`	Field access
Servlet	`SimpleServletComponent`	Field access
Servlet	`HttpServlet`	Setter method

Using service dependencies as described here is a required guideline for level 1 certification, see guideline /wiki/spaces/PD/pages/24721296 of the development guidelines.

...

Version	Old Version 14	New Version 15
Changes made by	Former user	Matthew Wagner
Saved on	Nov 23, 2016	Jan 30, 2017

Versions Compared

Key

OSGi Bundle Lifecycle

Plugin Management Console

Service Dependencies