Network Deployment (Distributed operating systems), v8.0 > Reference > Developer examples
Example: OSGi application manifest file
The OSGi bundles in an enterprise bundle archive (EBA) file share services with other OSGi applications by declaring them in an application manifest file, META-INF/APPLICATION.MF. Any external services and references that the OSGi application produces are exposed by declaring them in the manifest, and any external services and references that the application consumes are also declared in the manifest.
The application manifest describes modularity at the application level. It uses configuration by exception, that is, you supply values only when to override the default. An EBA file does not have to contain an application manifest file. The default, when no application manifest is declared, is that the application content is the set of OSGi bundles contained in the OSGi application, and no external services or references are produced or consumed.
The application manifest specifies the bundles that form the primary content of the application. A bundle that is listed in the primary content might use a package that is not included in the application, and therefore require other bundles to be pulled in. The application manifest might also specify an allowed version range for some bundles; this range defines the initial version of the application, and the latest version to which it can be upgraded.
Eclipse tooling provides convenient editors for the manifest file.
Here is an example application manifest file, META-INF/APPLICATION.MF:
Manifest-Version: 1.0 Application-ManifestVersion: 1.0 Application-Name: My Club Application-SymbolicName: com.myclub.app Application-Version: 1.0 Application-Content: com.myclub.api; version=1.0.0, com.myclub.persistence; version=1.0.0, com.myclub.web; version="[1.2.0,1.2.5)", com.myclub.common; version="(1.2.0,2.0.0)" Application-ImportService: com.myclub.security.authenticationService; filter="(security=strong)" Application-ExportService: com.myclub.memberService Use-Bundle: com.clubs.utils; version="[1.0.0,1.1.0)"
The metadata in an application manifest file includes the following headers:
If you do not specify a value, the default value is the application symbolic name.
The value must not be the same as the value of the Bundle-SymbolicName header for any bundle or composite bundle in the application, as listed in the Application-Content header.
sep2011
If you do not specify a value, the default value is the name of the EBA file.
If you do not specify a value but the application name contains an underscore character "_" followed by a valid version value, this value is used. For example, for the application name com.ibm.ws.eba.example_1.2.3.eba, the default value is 1.2.3.
Otherwise, if you do not specify a value, the default value is 0.0.0.
If you do not specify a value, the default is the modules that are contained directly in the root of the EBA file.
The format is a comma-separated list of module declarations, where each module declaration uses the following format:
bundle_symbolic_name;version
The version format is the same as that used for OSGi import (for example, in the Import-Package syntax).
The Application-Content header has the following attribute:
In OSGi syntax for a version range, brackets [ ] mean include the corresponding lower or upper limit, and parentheses ( ) mean exclude the corresponding lower or upper limit. For example, [1.0.0,2.0.0) means version 1.0.0 and all later versions, up to, but not including, 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, dependencies are analysed when the application is deployed and other bundles are provisioned. Any bundles that are provisioned cannot provide services external to the application and cannot have security applied to them. Such bundles are provisioned to the shared bundle space, rather than being provisioned for each isolated application.
If you do not specify this header, no services are imported. If you do not specify a value, the default is no values.
The format is a comma-separated list of services, in the form of a service interface name, followed by the filter attribute; this attribute specifies an OSGi service filter.
For example:
Application-ImportService: com.myclub.security.authenticationService; filter="(security=strong)"
Any services that match the Application-ImportService header are made available for integration, but to actually do the integration use Service Component Architecture (SCA). See Use OSGi applications as SCA component implementations.
Your remotable service must support pass-by-value semantics.
To match against services that are imported by the Application-ImportService header, your service references must look for the service.imported property.This prevents accidental exposure or use of services that only support local calls and expect pass-by-reference semantics.
If you do not specify this header, no services are exported. If you do not specify a value, the default is no values.
The format is a comma-separated list of services, in the form of a service interface name, followed by the filter attribute; this attribute specifies an OSGi service filter.
For example:
Application-ExportService: com.myclub.memberService; filter="(level=silver)"
Any services that match the Application-ExportService header are made available for integration, but to actually do the integration use Service Component Architecture (SCA). See Use OSGi applications as SCA component implementations.
Your remotable service must support pass-by-value semantics.
To match against services that are exported by the Application-ExportService header, your service must be configured as remotable (that is, registered with the service.exported.interfaces property).This prevents accidental exposure or use of services that only support local calls and expect pass-by-reference semantics.
Often, you do not require a Use-Bundle header, but there are some situations where it is useful. We 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.
Parent topic: Manifest files
Related concepts:
About OSGi Applications
Enterprise bundle archives
Related tasks:
Secure OSGi Applications
Related reference:
Example: OSGi bundle manifest file
Example: OSGi composite bundle manifest file
OSGi deployment manifest file
OSGi Applications: Troubleshooting tips
Reference topic
Feedback
Copyright IBM Corporation 2009, 2011. All Rights Reserved.
This information center is powered by Eclipse technology.