Migrate OSGi applications

For transitioning users: If we have a WAS v7 node that is augmented with the Feature Pack for OSGi and JPA 2.0 applications, and we federate the node into a WAS cell in v8.0 or later, the addNode command does not succeed. This problem occurs only when we 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. The solution is to augment our v7 node with Fix Pack 5, or later, of the Feature Pack for OSGi Applications and Java Persistence API 2.0. See troubleshooting tip An existing v7 application server augmented with the OSGi Applications feature cannot be federated into a Deployment Manager in v8.0 or later.trns

For transitioning users:

• In the WAS v7 Feature Pack for OSGi Applications and Java Persistence API 2.0, when we 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 we subsequently delete the composite bundle from the repository, the individually-available copies of the bundles are not deleted. We might have used this mechanism as a convenient way to upload sets of bundles to the repository.

• In the current version, when we 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 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.

trns

Migrate and coexisting for OSGi applications