OSGi defines a model to provide bundles with configurations. This is specified in the Configuration Admin specification where a configuration is identified by a persistent identity (PID). A PID is a unique token, recommended to be conforming to the symbolic name syntax. A configuration consists of a set of properties, where a property consists of a string key and a corresponding value. The type of the value is limited to the primitive types and their wrappers, Strings, or Java Arrays/List/Vector of these.
This specification defines a mechanism to feed configurations into the Configuration Admin Service through configuration resources. A single configuration resource can feed multiple PIDs with configuration and multiple configuration resources can be provided in one or more bundles.
The following entities are used in this specification.
-
Configuration Admin Service - Standard service to configure OSGi-based systems. See Configuration Admin Service Specification.
-
Configuration Resource - A JSON resource in a bundle containing configurations. This resource is processed by an implementation of this specification.
-
Extendee - The extendee is a bundle containing configuration resources. It is extended by an implementation of this specification.
-
Configurator - The Configurator implements the behavior specified in this specification. It processes configuration resources and passes the configuration dictionary on to the Configuration Admin Service.
-
Configuration dictionary - The configuration information when it is passed to the Configuration Admin Service. It consists of a
Dictionary
object with a number of properties and identifiers. -
Persistent Identity (PID) - A configuration dictionary is associated with a unique PID to identify the destination of this data. See The Persistent Identity.
-
Configuration Object - Implements the
Configuration
interface and contains the configuration dictionary for a Managed Service or one of the configuration dictionaries for a Managed Service Factory. These objects are manipulated by configuring bundles. -
Coordinator Service - The coordinator groups related operations to optimize handling of these operations. Using the coordinator with configuration updates can minimize the volatility in the system. See Coordinator Service Specification.
The Configurator is processing configuration resources containing configurations. The resources can either be part of a bundle or be provided to the Configurator on startup.
The format for a configuration resource is [1] JSON (JavaScript Object Notation) and it must be UTF-8 encoded. An example configuration resource has the following structure:
{
// Resource Format Version
":configurator:resource-version" : 1,
// First Configuration
"pid.a": {
"key": "val",
"some_number": 123
},
// Second Configuration
"pid.b": {
"a_boolean": true
}
}
Comments in the form of [2] JSMin (The JavaScript Minifier) comments are supported, that
is, any text on the same line after //
is ignored and any
text between /* */
is ignored.
Configuration resources provide a set of configuration
dictionaries each with a PID key to target a
specific PID in the Configuration Admin Service and zero or more
configuration values for this PID. Keys starting with the prefix
:configurator:
contain information about the resource or
instructions for the Configurator and therefore are not interpreted as
PIDs containing configurations. If a key contains an invalid PID, this
entry is ignored and the Configurator should log an error with the Log
Service if available.
The Configurator defines the following special keys on the resource level.
Table 150.1 Resource-level Configurator Keys
Key | Value type | Syntax | Description |
---|---|---|---|
|
Number | integer > 0 | The version of the configuration resource format. This
specification only supports version 1 . If this
entry is omitted then version 1 is assumed.
Resources specifying an unsupported or invalid version are
ignored and the Configurator should log an error with the Log
Service if available.
|
|
String | symbolic-name | The symbolic name of the configuration resource. If not specified the symbolic name of the bundle containing the resource is used. Mandatory for configuration resources that do not reside in a bundle. |
:configurator:version |
String | version | The version of this configuration resource. If not specified the version of the bundle containing the resource is used. Mandatory for configuration resources that do not reside in a bundle. |
Configuration resources provide a set of configuration dictionaries each with a PID key to target a specific PID in the Configuration Admin Service.
Factory configurations can be addressed using the
factory PID and a name by starting with the factory
PID, appending a tilde ('~' \u007e
), and then appending the
name. This ensures a well-known name for the factory configuration
instance. The PID for such a configuration is exactly this key. The
Configurator must use the getFactoryConfiguration
methods
on Configuration Admin Service to create or obtain configurations with
the given factory PID and name.
Targeted PIDs are supported through the configuration resource. In
the case of single configurations, the full targeted PID is used as the
key. For factory configurations, the key is assembled by chaining the
targeted factory PID, a tilde ('~' \u007e
), and the
name.
The Configurator obtains all configurations with the location
value of ?
to allow the configurations to be received by
multiple bundles.
The Configurator uses the
Configuration.updateIfDifferent
method on the configuration
object to avoid any volatility in the system if the configuration
applied has not been changed.
A configuration dictionary for the Configuration Admin Service is specified through a JSON object in the configuration resource. It is introduced using the PID as the key. The value is a JSON object containing the configuration dictionary.
The Configurator removes any comments and all properties where the
key is starting with the special prefix :configurator:
from
the configuration object before converting it to a configuration
dictionary that is provided to the Configuration Admin Service.
The Configurator defines special keys that can be used within the configuration object.
Table 150.2 PID-level Configurator Keys
Key | Value type | Syntax | Description |
---|---|---|---|
:configurator:policy |
String | default or force |
Specifies the overwrite policy on configurations set by non-Configurator sources. See Overwrite Policies. |
:configurator:ranking |
Number | integer | The ranking of this configuration. If multiple bundles provide configuration for the same PID ranking rules are used to decide which configuration gets applied, see Ranking. |
Configuration values support data types as specified with the Filter Syntax in the OSGi Core Specification. Configuration resources are specified in JSON, which supports a more basic set of data types. The following table describes how values are converted from JSON to configuration values.
Table 150.3 JSON Conversions
JSON type | To Java type |
---|---|
Boolean | Boolean |
Number |
Whole number: Floating point number: |
String | String |
Array | Array, or if requested Collection . Contents
are boxed. If the array contents are of the same JSON type, the
associated Java type is used as the array type. Otherwise the
array elements are converted to String and a
String[] array is used.
|
Object | Literal object as JSON String |
If a specific data type is required for a configuration, the
Configurator can be instructed to convert the JSON value to a given data
type. The target type can be specified by adding a colon :
and the desired data type to the property name. Supported data types are
String
, Integer
, Long
,
Float
, Double
, Byte
,
Short
, Character
and Boolean
.
Additionally arrays of Scalar or primitive types are supported and
Collection
of scalar. The primitive types that can be
specified for arrays are: int
, long
,
float
, double
, byte
,
short
, char
, boolean
. For
Collection
the Configurator picks a suitable implementation
that preserves order. Both bare Collection
as well as typed
collections that use the generics style notation are supported. If a
requested conversion cannot be performed, then the configuration is not
processed and the Configurator implementation should log an
error.
An example configuration resource with typed data:
{
"my.pid": {
"port:Integer" : 300,
"an_int_array:int[]" : [2, 3, 4],
"an_Integer_collection:Collection<Integer>" : [2, 3, 4],
"complex": {
"a" : 1,
"b" : "two"
}
}
}
The above configuration gets converted to a configuration dictionary with the following entries (in pseudo Java language):
Integer port = 300;
int[] an_int_array = {2, 3, 4};
Collection<Integer> an_Integer_collection = {2, 3, 4};
String complex = "{ \"1\" : 1, \"b\" : \"two\" }"
As an alternative of specifying data types for the Configurator, consumers of configuration can convert the configuration values to the desired type by using the OSGi Converter see Converter Specification. A convenient way to convert a configuration map to the desired data types is by using the Converter to convert it to an annotation instance or by using a Declarative Services component property type.
In some cases binary data is associated with configurations such
as certificates, security keys or other resources. The Configurator
can manage this binary data. The bundle developer places the binaries
in a location in the extendee and references it from the configuration
resource, marking its type as binary
:
{
"my.config": {
"security.enabled": true,
"public.key:binary" : "/OSGI-INF/files/mykey.pub"
}
}
When the Configurator applies the configuration, it extracts the binary file to a public area on the file system. The Configurator creates a subdirectory with as name the PID of the configuration. The PID must be URL-encoded to ensure that it does not contain characters that are illegal on a file system. The binary file is extracted in this subdirectory. The Configurator then applies the configuration with as value for the binary entry the absolute path of the extracted binary file.
A binary data property can also specify an array of binary
resources by declaring the binary[]
data type. Each
resource referenced is extracted as a separate file on the file system
and the value of the property will be an array of strings, each string
being the full path of one extracted binary.
By default a directory called binaries
in the
bundle data area of the Configurator implementation is used. An
alternative location can be specified via the
configurator.binaries
framework property. The value of
this property must be an absolute path on the file system to which the
Configurator has write access. If the directory does not exist the
Configurator will create it. If the Configurator cannot write to this
location, it logs an error and uses the default location
instead.
When a configuration is removed, its associated binary files are also removed from the file system. When a configuration is updated, associated binary files are updated, if necessary. In the case of an update the Configurator should use a different filename for the extracted binary file to avoid any open file lock issues.
The order in which the Configurator processes bundles is not defined. To control which configurations are in effect configuration ranking can be used. Configuration ranking is similar to service ranking; it is an integer which defaults to 0. Configurations with a higher ranking are preferred over configurations with a lower ranking. When multiple configurations arrive over time it is possible that the Configurator changes the effective configuration if a higher ranked configuration arrives later. The design of the Configurator is such that the effective set of configurations once the system stabilizes is consistent, regardless of the order in which bundles are installed and processed.
The ranking of a configuration can be specified by adding the
:configurator:ranking
property. The value of this property
is converted to an Integer
as defined by the Converter
specification. If the value cannot be converted a warning should be
logged. When multiple configurations for a given PID have the same
ranking the bundle providing the configuration with the lowest bundle ID
is preferred. If multiple configurations for the same PID with the same
ranking are specified within a single bundle, the first one encountered
is used.
The following example shows two bundles with a configuration resource containing a configuration for the same PID:
Resource in Bundle A:
{
"my.pid": {
"port:Integer" : 300,
":configurator:ranking" : 100
}
}
Resource in Bundle B:
{
"my.pid": {
"port:Integer" : 100,
":configurator:ranking" : 10
}
}
Bundle A contains the configuration with the higher ranking. Therefore, regardless of the installation order of bundle A and B, the configuration from Bundle A will be in effect after both bundles are installed and processed by the Configurator.
In an IT operations scenario configurations are often updated by a systems administrator to suit the deployments requirements. In such scenarios it may be undesirable to have these modifications overwritten by a software update which includes a configuration resource. In other cases, bundles with configuration resources are used to enforce best practices or compliance with corporate guidelines, which should replace any previous manual settings. This specification defines policies to define the overwrite behavior of the Configurator when configurations have been set or modified by another entity.
Configuration policies are set by specifying the
:configurator:policy
property. Accepted values are
default
and force
. This policy defines the
behavior when a configuration to be applied was set by another entity in
the system, or if it was modified by someone from the values set by the
Configurator. The default value for this property is
default
. If the specified value is invalid an error is
logged and the default value is used.
Table 150.4 Applying Configurations: Overwrite Policies
Policy value | Action |
---|---|
default |
No action |
force |
Configuration is added |
The Configurator must keep track of configuration change count values to identify configurations that were changed by other entities or administrators.
When a bundle that provides configuration resources is
uninstalled, the Configurator removes any configurations that it has
provided on behalf of this bundle from the system. Before it removes a
configuration the Configurator checks with the Configuration Admin
Service whether the configuration it has provided has been changed by
another entity. If the configuration has not been changed by another
entity it is removed. If it has been changed then whether the
configuration is removed depends on the value of the
configurator:policy
property:
Table 150.5 Removing externally modified configurations
Policy value | Action |
---|---|
default |
No action |
force |
Configuration is removed |
When a configuration is removed the Configurator checks whether another, lower ranked, configuration resource is available. If present the Configurator sets this configuration.
The following examples explain the two policy options. In the
first example Bundle A contains a configuration for the PID
my.pid
without specifying the policy. In this case the
default policy is used:
{
"my.pid": {
"port:Integer" : 300
}
}
The following actions demonstrate the behavior of the default policy:
-
The framework is started without any configuration for PID
my.pid
. -
Bundle A is installed, the Configurator creates the configuration for PID
my.pid
. -
An administrator manually changes the configuration for PID
my.pid
. -
Bundle A is updated with an updated configuration for PID
my.pid
. The Configurator detects the manual change of the configuration in Configuration Admin Service and does not apply the updated configuration from the bundle. -
Bundle A is uninstalled. The Configurator detects the manual change of the configuration in Configuration Admin Service and does not delete the configuration.
In the second example Bundle A contains a configuration for the
PID my.pid
this time with the overwrite policy set to
force
.
{
"my.pid": {
"port:Integer" : 300,
":configurator:policy" : "force"
}
}
The following actions demonstrate the behavior of the force policy:
-
The framework is started without any configuration for PID
my.pid
. -
Bundle A is installed, the Configurator creates the configuration for PID
my.pid
. -
An administrator manually changes the configuration for PID
my.pid
. -
Bundle A is updated with an updated configuration for PID
my.pid
. The Configurator applies the updated configuration. -
Bundle A is uninstalled. The Configurator detects the manual change of the configuration in Configuration Admin Service and deletes the configuration.
The Configurator follows the OSGi extender model and looks for JSON configuration resources in installed bundles, if the bundle has opted-in to be processed. In order to get processed, a bundle must require the Configurator extender:
Require-Capability: osgi.extender;
filter := "(&(osgi.extender=osgi.configurator)
(version>=1.0)(!(version>=2.0)))"
The Configurator must ensure to only process bundles that it is wired to by the resolver.
By default the configuration resources are in the
OSGI-INF/configurator
directory in the bundle.
Configuration files are UTF-8 encoded and have the
.json
file extension. Files not having this extension are
ignored. The Configurator processes the configuration resources within a
single bundle in lexical order using the full resource path for
sorting.
When the Configurator starts it calls
bundleContext.getProperty("configurator.initial")
to obtain
initial configurations from the runtime environment. If this property is
available its value is processed as follows:
-
If the value starts with a left curly bracket ('{'
\u007B
), ignoring any leading white space, the Configurator will interpret the value as a literal configuration JSON resource. -
Otherwise the value is treated as a comma-separated list of URLs. The Configurator will read the resource at each URL and parse it as a JSON Configuration resource. If any errors occur during this process they are logged and the URL is skipped. The URLs are processed in alphabetical order of their provided value.
The ranking of these configurations can be set in the configuration
resource as described in Ranking.
The Configurator treats the initial configurations as being provided from
a bundle with the bundle id -1
.
If the framework is restarted, the Configurator needs to check whether the provided initial configurations are different than on the previous startup. The implementation is free to use whatever is appropriate to perform this check, like comparing last modified for the URLs or using a hash etc. If the provided configuration is different than on a previous startup, this is treated like a bundle update with an updated configuration.
The Configurator uses the Configuration Admin Service. Therefore the Configurator implementation should require the Configuration Admin Service through a service requirement. The Configurator should not start processing configuration resources until it has runtime access to the Configuration Admin Service.
The Configurator uses the Configuration Admin Service that is visible to both the Configurator itself as well as the bundle that is being processed. If there are multiple candidates, the service with the highest ranking is used. If there is no Configuration Admin Service visible to both the bundle that is processed and the Configurator, the processing is delayed until such a service becomes available.
When the Configurator starts, it processes all started bundles and
applies configurations provided by those bundles. From then on, the
Configurator processes bundles as they enter the STARTING
state. The Configurator should process as many bundles as possible in a
single pass to minimize volatility for PIDs where multiple configurations
with different rankings are provided.
When a bundle containing configuration resources is updated, the configurations must be updated in the Configuration Admin Service to which they were originally provided, keeping in mind that the system might have been restarted in-between. One way of keeping track of the original Configuration Admin Service is via the bundle location of the bundle providing the service. If this service is not available the Configurator must attempt to apply the updated configuration when this Configuration Admin Service re-appears.
Configurations remain in the system until the bundle that provided the configurations is uninstalled. When this happens, the Configurator must uninstall the configurations from the Configuration Admin Service to which it originally installed it as is the case with updates. If this Configuration Admin Service is not available at this time, the Configurator must remember the configurations that are to be removed, and remove them when the Configuration Admin Service re-appears at a later time.
When the Configurator becomes active, it must check whether
configurations that it installed previously are still valid. If the
bundles that provided these configurations have been uninstalled, the
associated configurations must be removed. If a bundle is updated the
associated configurations are also updated. The Configurator calls
updateIfDifferent
on the configuration to avoid volatility in
the system if the actual configuration values did not change.
When updating or removing configurations, the Configurator must take the Overwrite Policies into account. This means that for certain policy values an externally modified configuration is not replaced or removed.
When a bundle that provides the Configuration Admin Service is uninstalled, the Configurator considers all configurations previously provided to that Configuration Admin Service as not yet applied. If another Configuration Admin Service is or becomes visible to both the Configurator and the bundle containing configuration resources, the Configurator will provide the configurations to this Configuration Admin Service as new.
When the Configurator is stopped or uninstalled the configurations applied will remain in the system.
The Coordinator Service Specification defines a mechanism for multiple parties to collaborate on a common task without a priori knowledge of who will collaborate in that task. The Configurator must participate in such scenarios to coordinate with provisioning or configuration tasks.
Whenever the Configurator is processing configuration resources and interacting with the Configuration Admin Service, the Configurator must check whether a Coordinator Service is present. If it is present, the Configurator checks for an implicit coordination on the current thread. If such an implicit coordination exists, the Configurator does not need to create one. However, if such an implicit coordination is not present, the Configurator starts an implicit coordination on the current thread when interacting with the Configuration Admin Service and ends this coordinator when it is finished doing the current set of work. The Configurator does not need to delay applying any changes to the Configuration Admin Service until the coordination ends.
When Java permissions are enabled, the Configurator must perform the following security procedures.
The Configurator manages configurations on behalf of the bundle
containing the configuration resources. Therefore the Configurator needs
to have the
ConfigurationPermission[*,org.osgi.service.cm.ConfigurationPermission.CONFIGURE]
.
Every bundle has the implicit right to receive and configure
configurations with a location that exactly matches the Bundle's
location or that is null
. Therefore the extendee does not
need to special permissions.
The Configurator needs ServicePermission[<interface>,
GET]
for the Coordinator
service.
The extendee needs ServicePermission[<interface>,
GET]
for the Configuration Admin Service.
The Configurator does get the Configuration Admin Service on behalf of the extendee. Therefore the extendee needs to be included in permission checks for getting the Configuration Admin Service. The Configurator needs to perform the required calls to ensure the extendee has the necessary permission to get the Configuration Admin Service.
If binaries are used, the Configurator needs to have read/write/delete permission to the configured directory to store the binaries.
A bundle using a binary referenced from a configuration needs to have read permission to correct sub directory of the configured binary directory. The subdirectory is named after the PID of the configuration.
By default binaries are stored in the bundle data are of the Configurator. While this works without Java security enabled, permission configuration for the extendees gets challenging as the location of the bundle data area is only known at runtime. Therefore with Java security enabled, the directory holding the binaries should be configured to allow permission configuration for the extendees.
The Configurator implementation bundle must provide the osgi.extender
capability with name osgi.configurator
with the version of
this specification:
Provide-Capability: osgi.extender;
osgi.extender="osgi.configurator";
version:Version="1.0"
This capability must follow the rules defined for the osgi.extender Namespace.
Bundles providing configuration resources must require the
osgi.extender
capability to opt in to being processed by
the Configurator. The default location for configuration resources is in
OSGI-INF/configurator
. A bundle can specify alternate
locations for configuration resources through the
configurations
attribute. The value of this attribute is of
type String
or List<String>
. Each value
represents a path inside the bundle. This path is always relative to the
root of the bundle and may start with a slash /
. A path
value of /
indicates the root of the bundle. The
Configurator uses Bundle.findEntries
to find all resources
with the .json
extension in this location. Sub directories
are not considered. If the configuration
attribute
specifies multiple paths, these are visited in the order specified.
Duplicate paths are ignored. Paths that do not exist in the bundle are
logged as an error and skipped. Resources in a single directory are
processed in alphabetical order. For example:
Require-Capability: osgi.extender;
filter:="(&(osgi.extender=osgi.configurator)
(version>=1.0)(!(version>=2.0)))";
configurations="resources/configs"
To simplify the creation of this requirement the RequireConfigurator annotation can be used. This annotation allows
the configurations
attribute to be defined is a value other
than the default is needed.
@RequireConfigurator("resources/configs")
Configuration resources define configuration for one or more PIDs.
To declare what configuration is being provided, the
osgi.configuration
capability namespace can be used.
Configuration resources and bundles can define the
osgi.configuration
capability for each configuration that
they define. This capability should have resolve time
effectiveness.
The osgi.configuration
Namespace supports the
attributes defined in the following table and ConfigurationNamespace.
Table 150.6 osgi.configuration namespace definition
Name | Kind | M/O | Type | Syntax | Description |
---|---|---|---|---|---|
service.pid |
CA |
O † |
String |
qname |
Defines the PID of the configuration. |
service.factoryPid |
CA |
O † |
String |
qname |
Defines the factory PID if this is a factory configuration. |
† Note that at least one of
service.pid
or service.factorypid
must be
defined. If the configuration is a standard configuration then only the
service.pid
is used. If the configuration is a factory
configuration with an automatically generated identity then only the
service.factoryPid
is used. If the configuration is a factory
configuration with a specified identity then both the
service.pid
and service.factoryPid
are
used.
The configuration file format in Configuration Resources defines a portable representation of configurations for the Configuration Admin Service. Whilst the Configurator implementation is necessary to process these configurations when they are packaged inside a bundle or provided on startup, these files can also offer significant value to other tools for deployment and management outside of the Configurator usage.
If configuration resources are used in an OSGi repository, in order to integrate with querying and the resolution process, the configuration resources should define the appropriate capabilities.
In addition to the common requirements and capabilities, a standalone configuration resource must declare the following capabilities when in an OSGi repository:
-
An
osgi.content
capability. The mime type of the configuration resource should beapplication/vnd.osgi.configuration+json
. -
An
osgi.identity
capability. This capability requires that each resource define a symbolic name and version. These can be obtained from the mandatory:configurator:symbolic-name
and:configurator:version
keys in the configuration resource. Astype
attribute the stringosgi.configuration
must be used.
Configurator Package Version 1.0.
Bundles wishing to use this package must list the package in the Import-Package header of the bundle's manifest. This package has two types of users: the consumers that use the API in this package and the providers that implement the API in this package.
Example import for consumers using the API in this package:
Import-Package: org.osgi.service.configurator; version="[1.0,2.0)"
Example import for providers implementing the API in this package:
Import-Package: org.osgi.service.configurator; version="[1.0,1.1)"
-
ConfiguratorConstants
- Defines standard constants for the Configurator services.
Defines standard constants for the Configurator services.
Framework property specifying the directory to be used by the Configurator to store binary files.
If a value is specified, the Configurator will write all binaries to the given directory. Therefore the Configurator bundle needs read and write access to this directory.
If this property is not specified, the Configurator will store all binary files in its bundle private data area.
The name of the extender capability attribute for the Configurator
Framework property specifying initial configurations to be applied by the Configurator on startup.
If the value of this property starts with a '{' (ignoring leading whitespace) it is interpreted as JSON and directly feed into the Configurator.
Otherwise the value is interpreted as a comma separated list of URLs pointing to JSON documents.
The version of the extender capability for the Configurator specification
Value for defining the default policy.
Value for defining the force policy.
Configuration property for the configuration policy.
Allowed values are POLICY_DEFAULT and POLICY_FORCE
Prefix to mark properties as input for the Configurator when processing a configuration resource.
Configuration property for the configuration ranking.
The value of this property must be convertible to a number.
Global property in the configuration resource specifying the version of the resource format.
Currently only version 1
is defined for the JSON format and
therefore the only allowed value is 1
for this property. If this
property is not specified, 1
is assumed.
Global property in the configuration resource specifying the symbolic name of the configuration resource. If not specified the symbolic name of the bundle containing the resource is used. Mandatory for configuration resources that do not reside in a bundle
Global property in the configuration resource specifying the version of the resource. If not specified the version of the bundle containing the resource is used. Mandatory for configuration resources that do not reside in a bundle.
Configurator Annotations Package Version 1.0.
This package contains annotations that can be used to require the Configurator extender.
Bundles should not normally need to import this package as the annotations are only used at build-time.
-
RequireConfigurator
- This annotation can be used to require the Configurator extender.
This annotation can be used to require the Configurator extender. It can be used directly, or as a meta-annotation.
This annotation allows users to define custom locations that should be searched for configuration files using RequireConfigurator.value()
CLASS
TYPE
, PACKAGE
This attribute can be used to define one or more locations that the configurator must search, in order, for configuration files.
If no locations are defined then the Configurator default of
/OSGI-INF/configurator
will be used.
A list of bundle locations containing configuration files
Configurator Namespace Package Version 1.0.
Bundles should not need to import this package at runtime since all the types in this package just contain constants for capability and requirement namespaces specified by the OSGi Working Group.
-
ConfigurationNamespace
- Configuration Capability and Requirement Namespace.
Configuration Capability and Requirement Namespace.
This class defines the names for the attributes and directives for this
namespace. All unspecified capability attributes are of type String
and are used as arbitrary matching attributes for the capability. The values
associated with the specified directive and attribute keys are of type
String
, unless otherwise indicated.
Immutable
Namespace name for configuration capabilities and requirements.
Also, the capability attribute used to specify the name of the extension.
The capability attribute contains the factory PID if this is a factory configuration. The value of this attribute must be of type String.
[1]JSON (JavaScript Object Notation) https://www.json.org
[2]JSMin (The JavaScript Minifier) https://www.crockford.com/javascript/jsmin.html