OSGi Bundle Compatibility Checking - projekt na verifikaci typové kompatibility OSGi komponent a jejich vazeb. Viz oficiální stránky na skupině DSS.
Co víme o součástech OSGi
Mostly with respect to compatibility evaluation, type matching.
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[]
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, 112.5.10)
- SCR uses term ``satisfied" for analogous state what in std osgi is ``resolved".
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 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).
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, sec 5.6.3 mandates filter syntax to be enhanced by version ranges).
- The OSGi suggested scheme is to be used.
Related resources
OSGi filters use LDAP filter syntax (RFC 4515) and matching rules (RFC 4517, partially explained in OpenDS wiki)
Miscellanea
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
Patří do KategorieProjekty.
