Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Lifecycle of an OSGi Bundle

 

OSGi bundle states

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

...

  1. update() is invoked.
  2. A check is done to see whether the version number of the plugin or bundle has been incremented and is higher than the currently installed version. If the version number is not correctly incremented, the update stops. If the version number is correctly incremented, the platform validity is checked.



    Note

    If the setting enable_wcb_development_mode in the XperienCentral Setup Tool (/web/setup) is set to “false”, this check is skipped.

  3. If the platform version is not valid, the update stops. If the platform is valid, the OSGi method bundle.update is invoked

...

LifecyclePurpose
onStart()

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

 

Code Block
themeEclipse
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
themeEclipse
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
themeEclipse
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
themeEclipse
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
themeEclipse
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
themeEclipse
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
themeEclipse
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
themeEclipse
public void onDestroy() {
   LOG.log(Level.INFO, “onDestroy() invoked!");
}


Dependencies: onDestroy() has no dependencies:

onStop()

onDestroy()

...

CommandPurpose
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:

  1. The plugin developer creates a 1.1 version of a plugin and gives it to a system administrator.
  2. 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.
  3. The system administrator determines the ID of the plugin in the Apache Felix Gogo shell.
  4. 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

  5. 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.

...

The exact classes in which the services are injected and the way they are injected depends on the component that defines the dependency. There are two ways the service might be injected into the component’s classes:

  • By Using Felix , by accessing the field directly. Felix injects the service in the class marked as implementation class (ComponentDefinitionImpl.setImplementationClassName) by manipulating a class member of which the type is the same as the one defined by the service dependency. Even if this field is private, Felix will still assign the service to this private field.
  • By Using XperienCentral , using a setter for the field in the class marked as instance class in the component definition (ComponentDefinitionImpl.setInstanceClassName). XperienCentral will try to find a setter for the field in this class with the same type as the service. If the setter exists, it will invoke that setter with the service.

...