14.3. OSGi Services Extension
Overview
Pax CDI also provides an integration with OSGi services, enabling you to reference an OSGi service or to publish an OSGi service using CDI annotations. This capability is provided by the Pax CDI OSGi Services Extension, which is not enabled by default.
Enabling the OSGi Services Extension
To enable the Pax CDI OSGi Services Extension, you must include the following bundle header in the manifest file:
Require-Capability : org.ops4j.pax.cdi.extension; filter:="(extension=pax-cdi-extension)"
In a Maven project, you would normally add a
Require-Capability element to the configuration of the Maven bundle plug-in. For example, to add both the Pax CDI Extender and the Pax CDI OSGi Services Extension to the bundle, configure your project's POM file, pom.xml, as follows:
<project ...>
...
<build>
<plugins>
...
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-SymbolicName>${project.groupId}.${project.artifactId}</Bundle-SymbolicName>
<Import-Package>*</Import-Package>
<Require-Capability>
osgi.extender; filter:="(osgi.extender=pax.cdi)",
org.ops4j.pax.cdi.extension; filter:="(extension=pax-cdi-extension)"
</Require-Capability>
</instructions>
</configuration>
</plugin>
...
</plugins>
</build>
...
</project>Maven dependency for the OSGi Services extensions API
To access the OSGi Services annotations in your Java code, you need to add a dependency on the
pax-cdi-api package. Edit your bundle's POM file, pom.xml, to add the Pax CDI API package as a Maven dependency:
<project ...>
...
<dependencies>
...
<!-- CDI API -->
<dependency>
<groupId>org.ops4j.pax.cdi</groupId>
<artifactId>pax-cdi-api</artifactId>
<version>1.0.0.RC1</version>
</dependency>
...
</dependencies>
...
</project>Injecting an OSGi Service
You can inject an OSGi service into a field using the following annotation:
@Inject @OsgiService private IceCreamService iceCream;
Pax CDI finds the OSGi service to inject by matching the type of the OSGi service to the type of the field.
Disambiguating OSGi Services
If there exists more than one OSGi service of a particular type, you can disambiguate the match by filtering on the OSGi service properties—for example:
@Inject @OsgiService(filter = "(&(flavour=chocolate)(lactose=false))") private IceCreamService iceCream;
As usual for OSGi services, the properties filter is defined using LDAP filter syntax (see the section called “Matching service properties with a filter” for more details). For an example of how to set properties on an OSGi service, see the section called “Setting OSGi Service properties”.
Selecting OSGi Services at run time
You can reference an OSGi service dynamically by injecting it as follows:
@Inject @OsgiService(dynamic = true) private Instance<IceCreamService> iceCreamServices;
Calling
iceCreamServices.get() will return an instance of the IceCreamService service at run time. With this approach, it is possible to reference an OSGi service that is created after your bean is created.
Publishing a bean as OSGi Service with singleton scope
You can publish an OSGi service with OSGi singleton scope (which is the default), as follows:
@OsgiServiceProvider
public class ChocolateService implements IceCreamService {
...
}
OSGi singleton scope means that the bean manager creates a single instance of the bean and returns that instance every time a bean instance is requested.
Publishing a bean as OSGi Service with prototype scope
You can publish an OSGi service with OSGi prototype scope, as follows:
@OsgiServiceProvider
@PrototypeScoped
public class ChocolateService implements IceCreamService {
...
}
OSGi prototype scope means that the bean manager creates a new bean instance every time a bean instance is requested.
Publishing a bean as OSGi Service with bundle scope
You can publish an OSGi service with bundle scope, as follows:
@OsgiServiceProvider
@BundleScoped
public class ChocolateService implements IceCreamService {
...
}
Bundle scope means that the bean manger creates a new bean instance for every client bundle. That is, the
@BundleScoped beans are registered with an org.osgi.framework.ServiceFactory.
Setting OSGi Service properties
You can set properties on an OSGi service by annotating the service bean as follows:
@OsgiServiceProvider
@Properties({
@Property(name = "flavour", value = "chocolate"),
@Property(name = "lactose", value = "false")
})
public class ChocolateService implements IceCreamService {
...
}Publishing an OSGi Service with explicit interfaces
You can explicitly specify the Java interfaces supported by an OSGi Service bean, as follows:
@OsgiServiceProvider(classes = {ChocolateService.class, IceCreamService.class})
public class ChocolateService implements IceCreamService {
...
}