How to obtain package and service bindings

Available interfaces and services in OSGi are

org.osgi.framework BundleContext :: getBundles() -> Bundle[] org.osgi.framework.Bundle :: getRegisteredServices() and getServicesInUse() org.osgi.service.packageadmin PackageAdmin :: getExportedPackages(Bundle bundle) -> ExportedPackage[] and getRequiredBundles(java.lang.String symbolicName) -> RequiredBundle[]

Version spec and matching:

• For capabilities, one of their property types is "version".
• For requirements, LDAP filters are used (example in section 5.5.7 of the OBR RFC shows it, sec 5.6.3 mandates filter syntax to be enhanced by version ranges).
• The OSGi suggested scheme is to be used.

Version spec and matching: For capabilities, one of their property types is "version". For requirements, LDAP filters are used (example in section 5.5.7 of the OBR RFC shows it, sec 5.6.3 mandates filter syntax to be enhanced by version ranges). The OSGi suggested scheme is to be used.

Bundle Repository (OBR) -- http://www.osgi.org/Repository/HomePage

Exported features are called "capabilities". Imported ones ("requirements") are actually named filter expressions.

Version spec and matching: For capabilities, one of their property types is "version". For requirements, LDAP filters are used (example in section 5.5.7 of the OBR RFC shows it). The OSGi suggested scheme is to be used.

Bundle Repository (OBR)

In OBR terminology, the exported features are called "capabilities" (and imported ones "requirements")

• sec 112.3.4 Selecting target svc is constrained by svc name and props, but exported services do not declare versions as first-class citizens (cf 112.4.6) so only the general mechanism of properties can be used (but these are on component, not service, level). Since the properties use LDAP syntax which allows wildcards, $\leq$ and $\geq$ operators, it should be possible to specify version range matching with the limitation that it would use string comparison.
• Explanation of R4 section 112.6 item 3: the rather complicated language says (if I understand correctly) that the target filter of a reference is available as the enclosing component's property with name (key in the property map) reference_name.target. E.g. for <reference name="factory" interface="f.q.name" target="(creation.method=shallow-copy)"> the filter is manifested in the enclosing component as property (112.3.4) factory.target="(creation.method=shallow-copy)". Thus we could have <reference name="xyz" \ldots target="(interface.version>=1.3.0)"> resulting in component's property xyz.target="(interface.version>=1.3.0).

Use of properties for version specification and matching:

• sec 112.3.4 Selecting target svc is constrained by svc name and props, but exported services do not declare versions as first-class citizens (cf 112.4.6) so only the general mechanism of properties can be used (but these are on component, not service, level). Since the properties use LDAP syntax which allows wildcards, $\leq$ and $\geq$ operators, it should be possible to specify version range matching with the limitation that

• Explanation of R4 section 112.6 item 3: the rather complicated language says (if I understand correctly) that the target filter of a reference is available as the enclosing component's property with name (key in the property map) reference_name.target. E.g. for <reference name="factory"

interface="f.q.name" target="(creation.method=shallow-copy)"> the filter is manifested in the enclosing component as property (112.3.4) factory.target="(creation.method=shallow-copy)". Thus we could have <reference name="xyz" \ldots target="(interface.version>=1.3.0)"> resulting in component's property xyz.target="(interface.version>=1.3.0).

Mostly with respect to compatibility evaluation, type matching.

• SCR uses term ``satisfied" for analogous state what in std osgi is ``resolved".

sec 112.3.4 Selecting target svc is constrained by svc name and props, but exported services do not declare versions as first-class citizens (cf 112.4.6) so only the general mechanism of properties can be used (but these are on component, not service, level). Since the properties use LDAP syntax which allows wildcards, $\leq$ and $\geq$ operators, it should be possible to specify version range matching with the limitation that it would use string comparison.

Explanation of R4 section 112.6 item 3: the rather complicated language says (if I understand correctly) that the target filter of a reference is available as the enclosing component's property with name (key in the property map) reference_name.target. E.g. for @@<reference name="factory" interface="f.q.name" target="(creation.method=shallow-copy)"> the filter is manifested in the enclosing component as property (112.3.4) factory.target="(creation.method=shallow-copy)"@@. Thus we could have <reference name="xyz" \ldots target="(interface.version>=1.3.0)"> resulting in component's property xyz.target="(interface.version>=1.3.0).

OSGi filters use LDAP filter syntax (RFC 4515) and matching rules (RFC 4517, partially explained in OpenDS wiki)

OSGi filters use LDAP filter syntax (RFC 4515) and matching rules (RFC 4517)

Related resources

OSGi filters use LDAP filter syntax (RFC 4515)

Miscellanea

• SCR allows re-binding to a different svc if it is available and the currently bound svc is shut down (sec 112.3.3, 112.5.10)

• SCR uses term ``satisfied for analogous state what in std osgi is ``resolved.

Co víme o součástech OSGi

Declarative Services Specification (SCR, after Service Component Runtime)

• SCR allows re-binding to a different svc if it is available and the currently bound svc is shut down (sec 112.3.3)

Aside: SCR uses ``event strategy'' for binding services which is in fact dependency injection - the component declares setter and unsetter methods to bind and unbind a reference, these are called by the SCR ie the framework

OSGi Bundle Compatibility Checking - projekt na verifikaci typové kompatibility OSGi komponent a jejich vazeb. Viz oficiální stránky na skupině DSS.

Patří do KategorieProjekty.