Network Deployment (Distributed operating systems), v8.0 > Administer applications and their environment > Administer OSGi applications > Export and importing a deployment manifest file > Import a deployment manifest


Import a deployment manifest using the importDeploymentManifest command

We can use this command to 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:

We can import a deployment manifest by using the wsadmin commands, as described in this topic, or by using administrative console, as described in Import a deployment manifest.


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.

We 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 need to pull in extra bundles to resolve the EBA asset.


Procedure

  1. Start the wsadmin scripting client if it is not already running.

  2. Use the importDeploymentManifest command. For example:
    AdminTask.importDeploymentManifest('[-asset
    com.ibm.ws.eba.example.blabber.app.eba -file /test/temp/DEPLOYMENT.MF]')
    
    The deployment manifest is checked to ensure that the bundles that it lists can be resolved.

  3. Save your changes to the master configuration.

    To save the configuration changes, use the following command:

    AdminConfig.save() The deployment manifest is imported into the EBA asset and any new bundles that are required to provision the application are downloaded. The file name changes to DEPLOYMENT.MF.

  4. 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:

    • Use 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.

  5. 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. We 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. Messages relating to any restart operations are written to the WAS SystemOut.log file.


Subtopics

Parent topic: Import a deployment manifest

Related concepts:

About OSGi Applications
Enterprise bundle archives

Related tasks:

Secure OSGi Applications
Deploy an OSGi application as a business-level application

Related reference:

OSGi Applications: Troubleshooting tips
OSGi deployment manifest file
Task topic Feedback
Copyright IBM Corporation 2009, 2011. All Rights Reserved.
This information center is powered by Eclipse technology.

+

Search Tips   |   Advanced Search