Tips for troubleshooting OSGi Applications support.
To help solve any unexpected problems with your deployed applications, you can debug the bundles at run time using the command-line console.
A list of the main known restrictions that apply when using OSGi Applications support is provided in OSGi Applications: Known restrictions.
If you have a WebSphere Application Server Version 7 node that is augmented with either the OSGi applications feature or the JPA 2.0 feature of the Feature Pack for OSGi Applications and Java Persistence API 2.0 prior to Fix Pack 5, and you federate the node into a WebSphere Application Server Version 8 cell, the addNode command does not succeed.
Running the addNode command from the /bin directory of the application server generates the following exception message:
com.ibm.websphere.management.exception.AdminException: addNode validation has failed. The OSGi Applications feature is installed on this node, but is not installed on the Deployment Manager. The Deployment Manager must also have the OSGi Applications feature installed. The node has not been added.
This problem occurs only when you try to federate a Version 7 node that has already been augmented with either the OSGi applications feature or the JPA 2.0 feature of the Feature Pack for OSGi Applications and Java Persistence API 2.0 prior to Fix Pack 5. To resolve the problem, augment your Version 7 node with Fix Pack 5, or later, of the Feature Pack for OSGi Applications and Java Persistence API 2.0. You can download the latest version of the feature pack from the Feature packs by version for WebSphere Application Server support page.
In the WebSphere Application Server Version 7 Feature Pack for OSGi Applications and Java Persistence API 2.0, bundle changes to the asset are applied by restarting the business-level application. In Version 8, these changes are applied by updating the composition unit. The current approach means that many bundle changes can be applied in place, without restarting the running business-level application.
To enable the current approach, the UpdateAppContentVersionsStep parameter has been replaced with the UpdateAppContentVersions parameter, and instead of restarting the business-level application you run the editCompUnit command with the CompUnitStatusStep parameter.
// *** Version 7 with OSGi Feature Pack script *** AdminTask.editAsset(' -assetID WebSphere:assetname=test.eba -UpdateAppContentVersionsStep [ [test.impl 1.0.0 1.1.0] [test.use.bundle 1.0.0 1.0.1] ] ') AdminConfig.save() // wait for downloads to complete by polling the BundleCacheManager MBean ... // restartBLA AdminTask.stopBLA(['-blaID', 'WebSphere:blaname=test']) AdminTask.startBLA(['-blaID', 'WebSphere:blaname=test']) // *** Version 8 script *** AdminTask.editAsset(' -assetID WebSphere:assetname=test.eba -UpdateAppContentVersions [ [test.impl 1.0.0 1.1.0] [test.use.bundle 1.0.0 1.0.1] ] ') AdminConfig.save() // wait for downloads to complete by polling the BundleCacheManager MBean ... AdminTask.editCompUnit('[ -cuID WebSphere:cuname=test_0001.eba -blaID WebSphere:blaname=test.app -CompUnitStatusStep [[WebSphere:asssetname=test.eba]] ]') // any number of AdminTask.editCompUnit items for new configuration AdminConfig.save() // no BLA restart
OSGi applications have one or more bundles listed in their Application-Content stanza, each with a given version range. The specific version of each bundle in use at a given time can be varied by creating a new deployment as described in Updating bundle versions for an EBA asset.
For WebSphere Application Server Version 8.0 and later versions, composite bundles can either be listed in the Application-Content stanza, or added to the deployed OSGi application as an extension. For a given application, you should not extend the application with a composite bundle that is already listed in the Application-Content stanza, and whose version is within the listed range for the composite bundle. If you do this, you might get unexpected results when you update the bundle versions.
You cannot assume that one bundle within an OSGi application will start or stop before another. If your application expects bundles to be started or stopped in a given order, it is unlikely to work in all environments.
The Blueprint programming model provides a way of declaring and dealing with inter-bundle service dependencies. If you cannot use Blueprint, you can use the ServiceTracker class, perhaps with an associated ServiceTrackerCustomizer to track services and react to changes in their status.
You have successfully installed your OSGi application. However, when you try and start the application it does not start.
Use the OSGi Applications command-line console to explore the framework for the application, and to debug specific bundles within the application. See Debugging bundles at run time using the command-line console.
You have an enterprise bundle archive (EBA) asset that uses a bundle that is in a repository. You import the asset, so the bundle is downloaded. If you then modify the bundle in the repository, but you do not change the version, the updated bundle is not downloaded again when an asset that requires this bundle is updated.
When you import an EBA file as an asset and save your changes to the master configuration, any missing dependencies are downloaded from the configured bundle repositories. You must wait until all the bundles are downloaded before you add the EBA asset to a business-level application.
You can view the download status of the bundles from the administrative console, or by calling the areAllDownloadsComplete () method of the BundleCacheManager MBean. See Interacting with the OSGi bundle cache.
If a bundle does not download, fix the cause (for example an incorrect repository address, or a network failure), then reset and retry the bundle download. See Interacting with the OSGi bundle cache.
When you map security roles to users or groups as described in Adding an EBA asset to a composition unit using wsadmin commands, you can specify that no users are bound to the role by setting the usernames parameter to the empty string "" - unless your application contains an ibm-application-bnd.xmi file.
The empty string "" means "use the default or existing value". If your application does not contain an ibm-application-bnd.xmi file, the default value is that no users are bound to the role. However, when an application contains an ibm-application-bnd.xmi file, the default value for usernames is obtained from this file.
If you are deploying an application that contains an ibm-application-bnd.xmi file, and you want to remove the bound users, specify just the "|" character (which is the separator for multiple user names). This explicitly specifies "no users", and therefore guarantees that no users are bound to the role.
When you start your OSGi application, any Blueprint bundles in the application try to satisfy their service dependencies. By default, the blueprint bundles continue to try to do this for five minutes before generating a timeout exception.
To check whether your Blueprint bundles have started, use the trace string org.apache.aries.blueprint.*=debug and check in the application server SystemOut.log file for GRACE_PERIOD messages. These messages tell you what, if anything, the Blueprint container is waiting for.