No special steps are required to migrate from the OSGi
Applications Feature Pack in WebSphere® Application
Server Version 7 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 Version 7, 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 made since Version
7
- 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.
- 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 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 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. 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.
- 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 you 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 Version 7. For example,
OSGi applications can use aspects of Java Platform,
Enterprise Edition (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 Version 7 nodes:
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.
Other version-related considerations
OSGi
applications that can run on Version 7 nodes are also supported on
Version 8 nodes. When you import an application written for Version
7 into a cell that includes Version 7 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 Version 7 into a cell that has no Version 7 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 Version 7 node to the cell and then reimport the application.
If
an application is running on a cluster, and the application cannot
run on a Version 7 node, the system will not allow you to add a Version
7 node to the cluster.
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. 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. For more
information, see An existing Version 7 application server augmented with the OSGi Applications feature cannot be federated into a Version 8 Deployment Manager.![[Updated in September 2011]](../deltaend.gif)
sep2011