Tips for troubleshooting OSGi Applications support.
To help you identify and resolve problems concerning OSGi Applications support, use the WebSphere® Application Server tracing and logging facilities. For more information about using tracing and logging, see Adding logging and tracing to your application.
WebSphere Application Server system messages are logged from a variety of sources, including application server components and applications. For more information about the system messages for the OSGi Applications component, see OSGi Applications: Messages. To enable trace for OSGi Applications, set the application server trace string to CWS??=all=enabled:Aries*=all=enabled. If you encounter a problem that you think might be related to OSGi Applications support, you can check for system messages in the WebSphere Application Server administrative console, and in the application server SystemOut.log file. You can also enable the application server debug trace to provide a detailed exception dump.
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.
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 do not change either the symbolic name or the version, the updated bundle is not downloaded again.
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 bundle download status of the asset from the administrative console by navigating to , or by calling the areAllDownloadsComplete () method of the BundleCacheManager MBean.
If a bundle does not download, fix the cause (for example an incorrect repository address, or a network failure), then use the BundleCacheManager MBean to reset and retry the bundle download.
When you map security roles to users or groups as described in Adding an EBA asset to a business-level application using the addCompUnit command, 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.