Subsystem Properties

Subsystem identifier – A long that is a Subsystems implementation assigned unique identifier for the full lifetime of an installed Subsystem, even if the framework or the Subsystem’s implementation is restarted. Its purpose is to distinguish Subsystems installed in a framework. Subsystem identifiers are assigned in ascending order to Subsystems when they are installed. The getSub-systemId() method returns a Subsystem's identifier.

Subsystem location – A name assigned by a management agent to a Subsystem during the installation. This string is normally interpreted as a URL to the Subsystem Archive but this is not mandatory. Within a particular framework, a Subsystem location must be unique. The getLocation() method returns a Subsystem's location.

Subsystem Symbolic Name and Subsystem Version – A name and version assigned by the developer. The combination of a Subsystem symbolic name and Subsystem version is intended to provide a globally unique identifier for a Subsystem Archive or Subsystem definition. The getSymbolic-Name() method returns the assigned Subsystem name. The getVersion() method returns the assigned version. Though this pair is intended to be unique, it is developer assigned and there is no verification at runtime that the pair uniquely identifies a Subsystem Archive. It is possible to install a Subsystem multiple times as long as the multiple Subsystem symbolic name and version pairs are isolated from each other by Subsystem sharing policies.

Subsystem type - A Subsystem definition may declare different types of content resources. They simplify the configuration of sharing policies. The type of Subsystem is specified using the Subsystem-Type header. Each type has its own default sharing policy, for example, to for-bid the sharing of capabilities out, or to share all capabilities in.

• osgi.subsystem.application - has sharing policy associated with what is often considered to be an application. An application does not share (export) any capabilities to other bundles or Subsystems. It also does not explicitly import any capabilities. Any required capabilities that are not satisfied by the application's constituents are automatically shared in (imported) from the parent Subsystem.
• osgi.subsystem.feature - defines an Unscoped Subsystem and therefore provides no isolation of its own. A feature Subsystem implicitly imports and exports all requirements and capabilities.
• osgi.subsystem.composite - has sharing policy that by default does not share anything with its parent and therefore all sharing is fully explicit. Capabilities, such as packages and services,may be explicitly imported into or exported out of the composite.

The value of the type property must match the type of the corresponding entry in the Subsystem-Content header, including taking into account defaulting. If the type does not match, then the installation will fail.