Importing a deployment manifest

You can import a suitable deployment manifest to an enterprise bundle archive (EBA) asset. When you import the file, the bundles are resolved. If the bundles cannot be resolved, the import does not complete and an exception message is generated.

Before you begin

The file to import must be a valid deployment manifest file, using the naming format file_name.MF, for example DEPLOYMENT_TEST.MF. When you import the deployment manifest into the EBA asset, the file is renamed to DEPLOYMENT.MF.

For the import to succeed, the following conditions must be met:
  • The deployment manifest to import must correspond with the application manifest of the OSGi application that is contained in the EBA asset.
  • The bundles and their versions that are listed in the deployment manifest must be available, either within the EBA file or from a bundle repository.
  • If the asset has previously been updated, the bundle downloads for the previous update must have completed. See Checking the bundle download status of an EBA asset.

You can import a deployment manifest by using the administrative console, as described in this topic, or by using wsadmin commands, as described in Importing a deployment manifest using the importDeploymentManifest command.

About this task

A deployment manifest file, META-INF/DEPLOYMENT.MF, is created automatically when you import an EBA asset. The deployment manifest file lists, at specific versions, all the bundles and composite bundles that make up the application, including bundles that are determined following dependency analysis. The manifest file is used to ensure that each time an application server starts, the bundles that make up the application are the same.

You can export the deployment manifest file from an application, then import the manifest file into another instance of the same application located somewhere else. This is useful during application development, when an application is fully tested and moves to a production environment. By importing the deployment manifest from the test environment, you ensure that the bundles and their versions that make up the application in the production environment are exactly the same as the bundles that make up the application in the test environment.

When you import a deployment manifest into an EBA asset, the content of the deployment manifest must correspond with the existing application manifest in the EBA asset.

The application resolving process checks whether the deployment manifest contains all the required bundles. It should not have to pull in extra bundles to resolve the EBA asset.

Procedure

  1. Start the administrative console.
  2. Navigate to Applications > Application Types > Assets.
  3. Click the name of the asset into which you want to import the deployment manifest.
    The Asset settings panel is displayed. If the bundle downloads for any previous update have completed, then the option to import a deployment manifest is displayed under the Additional Properties section.
  4. Click [Additional Properties] Import a deployment manifest into this application.

    The Import a deployment manifest into this application panel is displayed.

  5. Click Local file system or Remote file system, as required, then enter the fully-qualified path to the deployment manifest file that you want to import. The file must be a valid deployment manifest, with a .MF file extension.
  6. Click OK.
    The deployment manifest is checked to ensure that the bundles that it lists can be resolved, then it is imported into the EBA asset. The file name changes to DEPLOYMENT.MF. Any new bundles that are required to provision the application are downloaded.
  7. Save your changes to the configuration repository.
  8. Optional: Check the update status of the composition unit.
    If you plan to update the composition unit at this time, check the update status of the associated OSGi composition unit. This status is one of the following values:
    • Using latest OSGi application deployment.
    • New OSGi application deployment not yet available because it requires bundles that are still downloading.
    • New OSGi application deployment available.
    • New OSGi application deployment cannot be applied because bundle downloads have failed.
  9. Optional: Update the composition unit to the latest deployment.

    When all bundle downloads are complete, you can update the OSGi composition unit so that the business-level application uses the newer configuration. You do not have to update the composition unit every time you update the asset. If any of the updates contain configuration options, you update the configuration information. You can also take the opportunity to make additional, non-essential configuration changes.

    When you save the changes to the composition unit, the associated business-level application is updated to use the new configuration. If the business-level application is running, the bundle and configuration updates are applied immediately. If possible (that is, depending on the nature of the updates) the system applies the updates without restarting the application. If you update a bundle that provides only OSGi services to the rest of the application, then only that bundle is restarted. If you update a bundle that provides one or more packages to other bundles, then those bundles and any bundles to which they provide packages are restarted. If, however, a new package or service dependency is added, or an existing package or service dependency is removed, then the application is restarted; a newly added package and service can come from a newly-provisioned bundle, or from a bundle that has already been provisioned.