Menu
The OSGi Enterprise Release 5 Specification introduces the osgi.extender namespace. This namespace makes it possible for bundles that assume extenders such as Blueprint or Declarative Services are installed in the framework to model this dependency using the Require-Capability header.
Chapter 135.2 osgi.extender Namespace tells us that the value of the capability for each specific extender should be specified in the corresponding specification. An example is given for Blueprint:
Provide-Capability: osgi.extender;
osgi.extender="osgi.blueprint";
uses:="org.osgi.service.blueprint.container,org.osgi.service.blueprint.reflect"
version:Version="1.0"
However, chapter 112 Declarative Services Specification does not specify the capability that an SCR implementation provides.
Peter Kriens gives an example in a blog post on Requirements and Capabilities that suggests the capability for SCR is osgi.component. I assume that eventually this value will be properly defined in the specs. But until then I cannot use it.
Since the Require-Capability and Provide-Capability headers were introduced in OSGi Core Release 4.3 the mechanism is already available in framework implementations. So, I want my bundles to express a requirement on SCR so that an SCR implementation can be resolved from an OBR repository.
I can imagine one solution where I create an empty bundle that on one hand provides a custom capability and on the other hand require an implementation bundle. For example:
Provide-Capability: com.example.extender; extender=scr
Require-Bundle: org.apache.felix.scr; bundle-version=1.6.0
Any bundles that include declarative services can then express a requirement to this capability. For example:
Require-Capability: com.example.extender; filter:="(extender=scr)"
Is this a good way of making sure SCR is resolved when I deploy bundles that contain declarative services? Is there any other way?
A good solution to this problem would be a solution that can also be applied to other legacy bundles that don't provide capabilities.
556
OSGi declarative services are the OSGi way to handle the instantiation problem: the fact that we want to code to interfaces, but we need some way to instantiate classes and some way to provide some concrete instance of an interface in order for the parts of our modular application to work together.
Using the OSGI Declarative Service, the equivalent code would look something like this: Here the properties are defined with the help of an inner interface called as Config, which contains all the properties that need to defined within the web console configuration.
The @Component annotation makes the class an OSGi component. Setting a service property to a particular service type in the annotation, allows other components to reference the service component by the specified service type.
The spec has defined the osgi.extender namespace but the various extender specs (Blueprint, DS) need to be updated to mandate that implementations provide the proper extender capability. Right now, they probably don't.
So for now, there is now way for your DS bundle to "require" the DS implementation bundle to be resolved (or even installed).
OSGi has work in progress for the next updates of Blueprint and DS and these updates will mandate the osgi.extender capability.
157
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
