...
| Lifecycle | Purpose |
|---|
onStart() | Allows a component to attach logic to a start event. For example:
| Code Block |
|---|
| 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 |
|---|
| 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 |
|---|
| 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 |
|---|
| 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 |
|---|
| 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 |
|---|
| 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 |
|---|
| 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 |
|---|
| public void onDestroy() {
LOG.log(Level.INFO, “onDestroy() invoked!");
} |
Dependencies: onDestroy() has no dependencies: onStop()
onDestroy() |
...
Another XperienCentral specific tool for plugin management is the Plugin Management consoleconsole. This is a plugin available from the Configuration > Plugins menu item in XperienCentral. While the Felix Gogo shell provides access to the OSGi bundles only (and is unaware of plugin specific functionality), the Plugins Management Console provides access to plugin-specific lifecycle methods, like purge. For more information on the Plugin Management Console, refer to the XperienCentral online help. The Plugins Management Console appears as follows:
...
| 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 read/write node 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 instancesread-only nodes.
|
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.
|
|
...