+

Search Tips   |   Advanced Search

Provisioning for OSGi applications

When you import an enterprise bundle archive (EBA) file as an asset, or update an asset to use new bundle versions, or add a composite bundle as an extension to a composition unit, provisioning ensures that all the required OSGi bundles are available. An OSGi application can use bundles from external repositories, bundles from nternal repository, and bundles that are included in an EBA file or a composite bundle archive (CBA) file.

As an OSGi application becomes formalized, the developer creates an application manifest that lists all the bundles that the application uses directly. Of this set of bundles, the developer might choose to package up only newly-created bundles in the EBA file, expecting other bundles to be provisioned from the configured local and remote bundle repositories. Similarly, the developer of a composite bundle creates a composite bundle manifest that lists all the bundles that the composite bundle uses. Of this set of bundles, the developer might choose to package up some bundles to be directly available to the composite bundle, and expect other bundles to be provisioned from the configured bundle repositories.

OSGi bundles can be stored in the following locations:

Provisioning gets the following types of bundle from a repository:

Provisioning occurs for an EBA asset when the OSGi application is initially imported, and when the asset is subsequently updated. The asset is resolved; that is, the locations of the constituent application bundles, at appropriate versions, are determined by using the contents of the EBA file, nternal bundle repository, and the specified set of external bundle repositories. Similarly, provisioning occurs when we add a composite bundle as an extension to a composition unit. The locations of the constituent bundles, at appropriate versions, are determined using the contents of the composite bundle and the available bundle repositories.

Provisioning also checks for dependencies and locates them from the relevant bundle repositories. Dependencies include imported packages, required bundles, services, and persistence providers. The provisioning process detects service dependencies by checking the <service>, <reference>, and <reference-list> elements in the Blueprint XML files for a bundle. Bundles are scanned for Blueprint XML files when the bundles are added to nternal bundle repository, or when they are provided in an EBA or CBA file. If the application code makes direct programmatic use of OSGi services, provisioning does not detect those service dependencies unless they are also specified in the Blueprint XML files.

If a bundle is referenced in the application manifest with a range of possible versions, provisioning locates a bundle at a version in that range. If more than one version of a specified bundle is available, the latest version in the specified range is selected, unless selecting a later version prevents the application from resolving.

If a required package or service is available at the same version from both a bundle and a composite bundle, the provisioning process selects the package or service from the composite bundle.

If the constituent application bundles of an OSGi application resolve successfully, a deployment manifest is generated. This manifest lists all the bundles that the application requires, with the actual version of each bundle that the OSGi application will use. The deployment manifest includes all the bundles that are declared in the application manifest, and also any dependency bundles.

If the provisioning process establishes that a bundle that is listed in the Use-Bundle header in the application manifest does not provide any packages to bundles listed in the Deployed-Content header, that use bundle is not listed in the Deployed-UseBundle header in the deployment manifest. Also, unless that use bundle is required for another purpose, it is not listed in the Provision-Bundle header in the deployment manifest.

When the constituent application bundles resolve successfully and the configuration is saved, all the referenced bundles and dependency bundles are downloaded from either nternal bundle repository or external bundle repositories and stored locally in the bundle cache. This cache is cell-wide for network deployment configurations, and server-wide for single server configurations. If any constituent bundles cannot be located, the EBA asset does not resolve. Messages show which bundles cannot be located. Before we can continue with mport or update, you must make the relevant bundle available in one of the following ways:

When all bundle downloads are complete, we can add the asset to a business-level application, or update the OSGi composition unit, so that the business-level application uses the newer configuration.


Parent topic: OSGi applications


Related concepts

  • Application bundles, use bundles and provision bundles
  • Enterprise bundle archive installation
  • Enterprise bundle archive update


    Related tasks

  • Deploy an OSGi application as a business-level application
  • Update bundle versions for an EBA asset