OSGi applications
An OSGi application groups a set of bundles to provide a coherent business logic. The application can consist of different bundle types such as web enabled bundles and persistence enabled bundles.
Bundles in one OSGi application are isolated from bundles, services, or packages that are defined in another OSGi application, unless the bundles, services, or packages are explicitly shared by both applications. An OSGi application can either directly contain OSGi bundles or reference bundles that are hosted in an OSGi bundle repository.
The OSGi bundles in the application can share services with other OSGi applications. If an OSGi application produces any external services and references, they are explicitly exposed by declaring them in an application manifest. Similarly, any external services and references that the OSGi application consumes are declared in the application manifest. An OSGi application can also use metadata to enable the sharing of some of its constituent bundles in the system. Sharing in this way can reduce the memory and resource requirements of a system.
Archive content
- If an Application-Content header is not defined, the archive content defines the OSGi application content.
- If an Application-Content header is defined, the archive content defines an initial bundle repository from which bundles can be provisioned. If a bundle with a specific version is installed into a governed repository, and the bundle is also contained in an application archive, the bundle from the archive is used.
Application manifest
The application manifest, META-INF/APPLICATION.MF, describes modularity at the application level. By default, when application manifest is not declared, the application content is the set of OSGi bundles contained in the OSGi application and no external services or references are produced or consumed.
- Application-SymbolicName
The unique symbolic name of the OSGi application, using similar package notation to Java.
- Application-Version
The version of the application, using OSGi syntax for a bundle version.
- Application-Name
The name of the application.
- Application-ImportService
Declares the external dependencies of the bundle that are used by the OSGi Framework for bundle resolution. Specific versions or version ranges for each service can be declared.
A set of filters for external services that the application consumes. The application manifest must contain the classes that services require. If this header is not specified, none of the required services are imported.
Specify the required services in a comma-separated list with the service interface name first followed by attributes or directives.
For example:<service identifier>;<directives>;<attributes>
The Application-ImportService header has the following attribute:test.it;filter="some_filter"
- filter
- An OSGi service filter.
- Application-ExportService
Declares the services that are visible outside the bundle. Any service not declared here has visibility only within the bundle.
A set of filters for external services that the application produces. If this header is not specified, none of the required services are exported.
Specify the exported services in a comma-separated list with the service interface name first followed by attributes or directives.
For example:<service identifier>;<directives>;<attributes>
The Application-ExportService header has the following attribute:test.it;filter="some_filter"
- filter
- An OSGi service filter.
- Use-Bundle
A shared bundle that provides at least one package to an application bundle.
A list of bundles or composite bundles to use to satisfy the package dependencies of bundles in the Application-Content list. Each bundle or composite bundle in the Use-Bundle list must provide at least one package to at least one bundle in the Application-Content list. These bundles are provisioned into the shared bundle space at run time.
Often, you do not require a Use-Bundle header, but there are some situations where it is useful. You can use it to restrict the level at which sharing is possible. For example, you can ensure that an application uses the same bundle for package imports that it was tested with. Alternatively, you can ensure that two applications use the same bundle for package imports. By setting the restriction at application level, the bundle can remain flexible.
- Application-WebModules
List of non-OSGi dynamic web projects that are included in the application.
This header is not part of the OSGi standard.
- Application-Content
- A list of composite bundles, bundle fragments, and bundles with the acceptable range of OSGi version specifications that are included in the application.Tip: When including a bundle fragment in the Application-Content list, ensure that you include the host bundle for the fragment.The format is a comma-separated list of module declarations, where each module declaration uses the following format:
<module identifier>;<directives>;<attributes>
Typically, the module identifier is the symbolic name of a bundle. To reference a resource that is not a bundle, the module identifier is the path relative to the OSGi application root.
The Application-Content header has the following attribute:- version
- The version of the module is specified using OSGi syntax for a version range. Specify the minimum version of the application followed by the maximum version to which the application can be upgraded. For example, "[1.0.0,2.0.0)" means version 1.0.0 and all later versions up to, but excluding, version 2.0.0.
The Application-Content header defines the important applications that compose the business services, but it does not define the full list of bundles in the application. If a bundle that is listed in the content uses a package that is not included in the application, a dependency analysis is performed and any missing bundles are included. These bundles cannot provide services external to the application and cannot have security applied to them. Bundles that are included using this mechanism are shared.
Deployment manifest
When an OSGi application is installed, the application manifest specifies the bundles that comprise an application. It can specify more than one version for some bundles.
The deployment manifest, META-INF/DEPLOYMENT.MF, specifies all the bundles that make up the application, including bundles that are required following dependency analysis. The deployment manifest specifies the actual version of each bundle that is used in the application. It is created automatically when an Enterprise Bundle Archive (EBA) asset is installed and it ensures that each time an application server starts, the bundles that make up the application are the same.
An EBA defines a set of OSGi bundles that are deployed as a single OSGi application, and that are isolated from other OSGi applications. An EBA file is a single archive file with a .eba file extension. It contains either a set of application modules or an application manifest, or both.
After an application is installed, the version of a bundle can be updated by configuring the EBA asset.
- Application-SymbolicName
- The unique symbolic name of the application, using similar package notation to Java. This matches the Application-SymbolicName value in the application manifest.
- Application-Version
- The version of the application, using OSGi syntax for a bundle version. This matches the Application-Version value in the application manifest.
- Deployed-Content
A comma-separated list of the symbolic names of the bundles and the exact versions to use.
The list includes all the bundles that are listed in the Application-Content header in the application manifest, and bundles that are imported by dependency analysis. Non-OSGi module types are included using the symbolic name of the converted bundle.
The Deployed-Content header has the following directive:- deployed-version
- The exact version of the bundle, specified using OSGi syntax for a version.