Network Deployment (Distributed operating systems), v8.0 > Reference > Troubleshoot tips > Troubleshoot OSGi applications
Migrate and coexisting for OSGi applications
No special steps are required to migrate from the OSGi Applications Feature Pack in WAS v7 to the current version. Enhancements made since Version 7 can affect how you configure your OSGi applications, particularly for working in mixed cells.
To migrate your OSGi applications and associated configuration from v7, follow the platform-specific instructions given in the "Migrating, coexisting, and interoperating" section of the information center. When you reach the point in the migration process when you run the WASPostUpgrade command (with the includeApps parameter set to TRUE), the following resources are migrated to the current version of the product:
- The OSGi applications
- The contents of the internal bundle repository
- Any links to external bundle repositories
- The contents of the bundle cache
After we have migrated the configuration, or if you want to run OSGi applications on v7 nodes in mixed cells, you will find it useful to understand the main enhancements made since Version 7, and the implication of those enhancements for using the applications with different versions of the application server:
- Main enhancements made since v7
- Current version enhanced support for v7 nodes
- Version-related considerations for composite bundles
- Version-related considerations for application types
- Other version-related considerations
Main enhancements made since Version 7
- In v7, all composite bundles are stored in bundle repositories. In the current version, composite bundles that are part of an OSGi application can also be directly included in the enterprise bundle archive (EBA) file.
- In the current version, you can include composite bundles in the Application-Content header of the application manifest file, so they can be treated as isolated rather than shared bundles.
- In the current version, you can extend an application by adding a composite bundle as an extension to the composition unit.
- In v7, when you add a composite bundle to the internal bundle repository, and that composite bundle directly contains bundles (in compressed files in the root directory of the composite bundle archive file), those bundles are added to the internal bundle repository both as part of the composite bundle and as individually-available bundles. If you subsequently delete the composite bundle from the repository, the individually-available copies of the bundles are not deleted.
- In the current version, when you add to the repository a composite bundle that directly contains bundles, those bundles are not also added individually. To add sets of bundles to the internal bundle repository, you package each set as a compressed archive file with a .zip file extension, then add the archive file to the repository. The system expands the file, and all the bundles in its root directory are added individually to the repository.
- In v7, bundle changes to the asset are applied by restarting the business-level application. In the current version, 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.
- In the current version, you can make post-configuration changes (for example configuring a new or changed Blueprint resource reference, or security role mapping) after we have deployed the application.
- In the current version, web archive bundles (WABs) can contain Run-As role metadata.
- In the current version, OSGi applications can use other features that have been added to the product since v7. For example, OSGi applications can use aspects of Java EE 6, such as Java Servlet 3.0.
- In the current version, the bundle cache is automatically cleaned whenever you uninstall an asset.
Current version enhanced support for Version 7 nodes
In a mixed cell, the current version provides the following enhancements to help support the v7 nodes:
- We can use the current administrative process for bundle changes to update all the nodes in a cell. For the current version nodes, the runtime environment usually applies the changes without restarting the running business-level application. For the v7 nodes, the runtime environment always restarts the business-level application.
- We can make post-configuration changes to applications that are deployed on any node in the cell, including the v7 nodes.
- When you uninstall an asset, the bundle cache is automatically cleaned for all nodes in the cell, including the v7 nodes.
There are slight differences in behavior for Version 7 nodes on the Windows platform, where file-locking constraints can mean that bundles are only deleted from the bundle cache for a node after the node has been restarted and another sync event has occurred.
Version-related considerations for composite bundles
A composite bundle cannot be used by an application running on a v7 server if any of the following conditions apply:
- The application includes a composite bundle directly in its EBA file.
- The application references the composite bundle in the Application-Content header of the application manifest file.
- The application has been extended by adding a composite bundle to the composition unit.
- The application pulls in individual bundles from a composite bundle stored in the internal bundle repository.
In the current version, if you want the bundles from a composite bundle stored in the internal bundle repository to also be individually available to applications, you first add the composite bundle to the repository; then you take the bundles that are directly contained in the root directory of the CBA file, package them as a compressed archive file with a .zip file extension, then add the archive file to the repository. The system expands the file, and all the bundles in its root directory are added individually to the repository.
Version-related considerations for application types
The following types of OSGi application cannot run on a v7 server:
- Applications that contain WABs with Run-As role metadata.
- Applications that use composite bundles as described in Version-related considerations for composite bundles.
- Applications that use other features that are not supported in Version 7. For example, Java Servlet 3.0.
Other version-related considerations
OSGi applications that can run on v7 nodes are also supported on v8 nodes. When you import an application written for Version 7 into a cell that includes v7 nodes, the runtime environment automatically provides the extra support needed to host the application on all the nodes in the cell. However, if you import an application written for v7 into a cell that has no v7 nodes, the runtime environment assumes that you are importing a current version application and the application might not run.
To solve this problem, add a v7 node to the cell and then reimport the application.
If an application is running on a cluster, and the application cannot run on a v7 node, the system will not allow you to add a Version 7 node to the cluster.
If we have a WAS v7 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 WAS v8 cell, the addNode command does not succeed. This problem occurs only when you try to federate a v7 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. See An existing v7 application server augmented with the OSGi Applications feature cannot be federated into a v8 Deployment Manager.
sep2011
Related concepts:
About OSGi ApplicationsRelated tasks:
Secure OSGi ApplicationsRelated reference:
OSGi Applications: Troubleshooting tips
OSGi Applications: Known restrictions
Reference topic Feedback
Copyright IBM Corporation 2009, 2011. All Rights Reserved.
This information center is powered by Eclipse technology.