Migrating and coexisting for OSGi applications

No special steps are required to migrate your OSGi application environment from previous versions of WebSphere® Application Server 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 a previous version, 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 you have migrated your configuration, or if you want to run OSGi applications on Version 7 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 your applications with different versions of the application server:

Main enhancements in Version 8

  • In Version 7, 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.
  • 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.
  • You can extend an application by adding a composite bundle as an extension to the composition unit.
  • In Version 7, 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 later 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. If you want 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 Version 7, 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.
  • You can make post-configuration changes (for example configuring a new or changed Blueprint resource reference, or security role mapping) after you have deployed the application.
  • Web application bundles (WABs) can contain Run-As role metadata.
  • OSGi applications can use other features that have been added to the product since Version 7. For example, OSGi applications can use aspects of Java™ Platform, Enterprise Edition (Java EE) 6, such as Java Servlet 3.0.
  • The bundle cache is automatically cleaned whenever you uninstall an asset.

Main enhancements in Version 8.5

  • Your OSGi applications can contain Enterprise JavaBeans (EJBs). The enterprise beans in your OSGi bundles can be developed from scratch, or you can include existing EJB assets and migrate them to use OSGi modularity with minimal code changes. Stateful, stateless, and singleton enterprise beans are supported. Your OSGi application can also contain message-driven beans (MDBs).
  • You can configure bean security in the Blueprint XML file of your OSGi applications, so that the methods of the bean can be accessed only by users that are assigned a specified role. You can configure bean-level security, so that a single role is associated with all the methods of the bean, or you can configure method-level security, where different roles are associated with specific methods.

Current version enhanced support for Version 7 nodes

In a mixed cell, the current version provides the following enhancements to help support the Version 7 nodes:
  • You 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 Version 7 nodes, the runtime environment always restarts the business-level application.
  • You can make post-configuration changes to applications that are deployed on any node in the cell, including the Version 7 nodes.
  • When you uninstall an asset, the bundle cache is automatically cleaned for all nodes in the cell, including the Version 7 nodes.
    For distributed platformsNote: 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 Version 7 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 that is stored in the internal bundle repository.
    Note: In the current version, if you want the bundles from a composite bundle that is 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 Version 7 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.