Provides information about the implementation of OSGi Subsystem specification.
Overview
The implementation of OSGi Subsystem specification provides subsystem management functionality. A subsystem is represented by a set of resources, which has own import/export policy. Currently supported resources are: bundles and subsystems. All subsystems are hierarchically ordered in a directed acyclic graph (which in most user cases is a tree). Subsystem service supports the following operations:
Install - installing from an archive, input stream, or an URI.
Start - starting dependent resources.
Stop - stopping dependent resource.
Update - replacing subsystem contents (works with an archive or an input stream). This operation is not defined in the OSGi specification.
Uninstall - uninstalling installed resources.
Auto-completion of subsystem file names is supported to allow deploying subsystems with build version suffix and installing them only by the name. For its usage and example refer to Auto-completion of Subsystem File Names.
When a subsystem implementation bundle is activated, a root subsystem is registered, containing all currently installed bundles.
Each installed subsystem, except the root, has its parent subsystem(s).
When a subsystem is installed, it becomes child of the subsystem from which it was installed.
When a bundle is installed explicitly (BundleContext#installBundle), it becomes part of the subsystem(s) which contain the bundle from BundleContext#getBundle.
Each uninstalled subsystem uninstalls its child subsystems.
Subsystem Resource
The Subsystem implementation provides a public Subsystem API (refer to Java API) for access and modification. Following functionality is supported:
Getting symbolic name, version, id (unique), location (unique).
Getting headers (localization is supported).
Getting type (application, composite and feature are supported).
Starting, stopping and uninstalling the subsystem.
Registering an OSGi service with objectClass org.osgi.service.subsystem.Subsystem with properties containing its symbolic name, version, id, type and state. The service is modified each time the state is changed.
Subsystem Policies, Types and Regions
Policies
Export Policy – defines the set of capabilities provided by the constituents, contained in the Region, that are made available to the parent Region.
Import Policy – defines the set of capabilities which are available in the parent Region, that are made available to the child Region.
Types
Following types are supported:
Application (osgi.subsystem.application) – defines its own region. Does not export anything to its parent(s). Imports all needed capabilities from its parent(s)/children.
Composite (osgi.subsystem.composite) – defines its own region. All its imports from children and exports to parent(s)/children must be described in a manifest (SUBSYSTEM.MF).
Feature (osgi.subsystem.feature) – does not define a region. It uses the region of the installer subsystem. Implicitly imports and exports all capabilities.
Regions
Each region defines its own sharing policy. It is determined by the main subsystem type in the region (application or composite). Root subsystems are always of type application.
Sharing Policy and Visibility
Each subsystem region provides isolation of its own. This functionality covers package imports/exports, generic capabilities (except for osgi.native and osgi.ee), bundle and service visibility, and event filtering.
Application subsystem regions have access to all capabilities exported from their children or required from their parent(s).
Composite subsystem regions have access only to implicitly required capabilities.
Feature subsystems have access to all available capabilities in a region.
