Conditions (ADD LINK TO CORE SPEC) can be used, to describe simple or complex runtime states. A Condition In and of itself is nothing more then a standardized way to announce themself to the Framework. The Condition Factory is intended to provide a configurable mechanism to aggregate complex states of your system by checking for the availability or absence of services. It then will provide a predefined Condition other services can track.
-
Condition - A requirement somebody needs fulfilled at runtime.
-
Condition Factory - A factory to aggregate complex states of your system and register a Condition if all requirements are fulfilled.
The implementation of the ConditionFactory must register a org.osgi.service.cm.ManagedServiceFactory with the service PID osgi.condition.factory. A configuration it might receive via ConfigurationAdmin can contain two lists of target filters. One for filters that MUST find at least one Service each in order to have a Condition registered. The other one represents a List of filters, that MUST NOT find any matching service. The moment all the included
and non of the exclude filters match, a Condition is registered with the given identifier and the additional properties. If any of the include Services go away or an excluded
Service becomes available, this Condition must be unregistered.
In case no match filters of any kind are given, the a condition will be registered the moment the configuration will be applied.
Table 156.1 Properties
| Service Property | Type | Description |
|---|---|---|
|
|
required |
The |
|
|
optional |
Properties like this will be registered with the condition, if all filters are satisfied. condtion.properties. will be cut away and the key will become the * part. |
|
|
optional |
The value of this service property is a List of LDAP-style filter expressions. A |
|
|
optional |
The value of this service property is a List of LDAP-style filter expressions. A |
An example Configuration utilizing the Configurator Specification is listed below
{
":configurator:resource-version": 1,
"osgi.condition.factory~test" : {
"condition.id" : "resulting.condition.id",
"condition.properties.custom.condition.prop" : "my.property",
"match.all" : [
"(&(objectClass=org.foo.Bar)(my.prop=foo))",
"(my.prop=bar)"
],
"match.none" : [
"(&(objectClass=org.foo.Fizz)(my.prop=buzz))"
]
}
}Requires ??? to register and get Conditions
Requires permission to use the config Admin?
Condition Factory Service 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.conditionfactory; version="[1.0,2.0)"
Example import for providers implementing the API in this package:
Import-Package: org.osgi.service.conditionfactory; version="[1.0,1.1)"
-
ConditionFactoryConstants- Defines standard names for Condition Factory configurations.
Defines standard names for Condition Factory configurations.
Thread-safe
A condition factory configuration property identifying the condition's unique identifier that will be used to register the condition when all the match filters are satisfied.
A condition factory configuration property identifying a list of target
filters for the condition. The condition may be registered when each
filter matches at least one service registration. The value of this
configuration property must be of type Collection<String>.
A condition factory configuration property identifying a list of target
filters for the condition. The condition may not be registered if any of
the target filters match at least one service registration. The value of
this configuration property must be of type Collection<String>.
The PID for the condition factory. The PID used to configure conditions with the condition factory.
A condition factory configuration property prefix identifying a service
property of the condition. The service property key is the remaining
content of the configuration property after the prefix. For example, a
configuration that contains
osgi.condition.configure.properties.prop1=value1 results in a
service property prop1=value1 when the condition is registered.