The CDI Extender reads CDI metadata from started CDI bundles. These metadata are in the form of XML documents, annotation types and requirements which define the set of beans available to the CDI container. Beans express dependencies on OSGi configuration objects and services and are assembled into components. The life cycle of a component is driven from the dependencies of its beans.

There are three types of components:

Figure 152.1 CCR Model

The creation and destruction of the component scope's contexts must adhere to the following process:

The container component must be configurable using it's container id as a PID; referred to as the container PID.

containerPID ::= < container id >

Given a bundle with Bundle-SymbolicName equal to com.acme.bar which does not set the container.id attribute in the requirement, the container id would be:

osgi.cdi.com.acme.bar

From the requirement example above where the container id is set to my.id, the container PID would be:

my.id

The configuration object used to satisfy the container PID must be a single configuration object. However the configuration policy for this configuration object is optional and is not required to satisfy the container component.

The container component is largely synonymous with the CDI container. When the dependencies of the container component are satisfied the CDI container completes it's initialization process and subsequently is fully functional. When the dependencies of the container component are no longer satisfied the CDI container is shutdown and all contextual instances are destroyed.

A container component with no beans would be immediately satisfied since it specifies no dependencies.

Annotations are not inherited unless meta-annotated by @java.lang.annotation.Inherited.

This specification provides several source code examples. In order to avoid repetition the following Java types are defined and re-used throughout:

interface Dog {}

interface Hound extends Dog {}

abstract class BassetHound implements Hound {}

class Spot extends BassetHound {}

class Buddy implements Hound {}

The @SingleComponent annotation is a stereotype which carries the @javax.inject.Named meta-annotation. This indicates that the default component name is:

For example:

// component.name = fido
@SingleComponent
class Fido {}

However, the name may be specified by adding @javax.inject.Named directly to the bean and specifying a value whose syntax follows cname defined by the [11] General Syntax Definitions.

// component.name = Champ
@SingleComponent
@Named("Champ")
class Fido {}

By default a single component must be configurable by using it's component name, prefixed by the container PID and a period (.), as a configuration PID. This component PID will be represented throughout the remained of the specification by the symbol Φ (capital Phi).

Φ           ::= containerPID '.' compName
containerPID ::= < container PID >
compName     ::= < component name >

A single component may change or add additional PIDs on which it depends. When multiple PIDs are referenced the order is relevant and affects the aggregation of the configuration objects into a flattened dictionary of component properties. Later PIDs take precedence over earlier PIDs. Also, it must be possible to reposition the component PID within the order. The PID annotation is used to control both referenced PIDs and their order.

The following is an example of a component that is configurable by it's component PID:

// component pids = [Φ]
@SingleComponent
class Fido {}

An example of a component replacing it's component PID with a specific PID:

// component pids = [com.acme.foo]
@SingleComponent
@PID("com.acme.foo")
class Fido {}

An example of multiple PIDs:

// component pids = [com.acme.foo, com.gamma.bar]
@SingleComponent
@PID("com.acme.foo")
@PID("com.gamma.bar")
class Fido {}

See Component Properties for how multiple component PIDs are merged into component properties.

Using @PID without arguments refers to the component PID:

// component pids = [Φ]
@SingleComponent
@PID
class Fido {}

This allows the component PID to be included anywhere in the order:

// component pids = [com.acme.foo, Φ, com.gamma.bar]
@SingleComponent
@PID("com.acme.foo")
@PID
@PID("com.gamma.bar")
class Fido {}

Each @PID annotation may specify a policy for the configuration object. The property policy is used to specify the value. The possible values are:

// component pids = [com.acme.foo, Φ, com.gamma.bar]
@SingleComponent
@PID(value = "com.acme.foo", policy = Policy.REQUIRED)
@PID
@PID("com.gamma.bar")
class Fido {}

It is a definition error to refer to the same PID more than once.

The configuration objects used to satisfy the single component's referenced PIDs must be single configuration objects.

The @FactoryComponent annotation is a stereotype which carries the @javax.inject.Named meta-annotation. This indicates that the default component name is:

For example:

// component.name = fido
@FactoryComponent
class Fido {}

However, the name may be specified by adding @javax.inject.Named directly to the bean and specifying a value whose syntax follows cname defined by the [11] General Syntax Definitions.

// component.name = Champ
@FactoryComponent
@Named("Champ")
class Fido {}

By default a factory component must be configurable by using it's component name, prefixed by the container PID and a period (.), as a factory PID. This component factory PID will be represented throughout the remained of the specification by the symbol Σ (capital Sigma).

Σ            ::= containerPID '.' compName
containerPID ::= < container PID >
compName     ::= < component name >

An example of a factory component that is configurable by it's component factory PID:

// component pids = [Σ]
@FactoryComponent
class Fido {}

A factory component may specify a factory PID using it's value property. The value must conform to the syntax defined for the Bundle-SymbolicName header.

An example of a factory component specifying a factory PID:

// component pids = [com.acme.foo-####]
@FactoryComponent("com.acme.foo")
class Fido {}

A factory component may change or add additional PIDs on which it depends. When multiple PIDs are referenced the order is relevant and affects the aggregation of the configuration objects into a flattened dictionary of component properties. Later PIDs take precedence over earlier PIDs. The PID annotation is used to control both referenced PIDs and their order.

An example of multiple PIDs:

// component pids = [com.gamma.bar, com.acme.foo-####]
@FactoryComponent("com.acme.foo")
@PID("com.gamma.bar")
class Fido {}

Each @PID annotation may specify a policy for the configuration dependency. The property policy is used to specify the value. The possible values are:

// component pids [com.acme.foo, com.gamma.bar, Σ]
@FactoryComponent
@PID(value = "com.acme.foo", policy = Policy.REQUIRED)
@PID("com.gamma.bar")
class Fido {}

See Component Properties for how multiple component PIDs are merged into component properties.

The component factory PID always reserves the highest precedence among specified PIDs and is positioned last in PID ordering for the purpose of aggregation

A factory component can only reference a single factory PID.

Notwithstanding the factory PID, it is a definition error to refer to the same PID more than once.

The configuration object used to satisfy the factory component's component factory PID must be a factory configuration object.

Configuration objects used to satisfy the PIDs referred to by the @PID annotations must be single configuration objects.

This specification defines some component properties which are associated with a specific reference. These are called reference properties. The name of a reference property for a reference is the name of the reference appended with a full stop ('.' \u002E) and a suffix unique to the reference property. Reference properties can be set wherever component properties can be set.

All component property names starting with a reference name followed by a full stop ('.' \u002E) are reserved for use by this specification.

Following are the reference properties defined by this specification.

target  ::= refName '.target'
refName ::= < reference name >

@Inject
@Reference
Http http;

http.target=(context.name=foo)

minimumCardinality ::= refName '.cardinality.minimum'
refName            ::= < reference name >

@Inject
@Reference
Http http;

http.cardinality.minimum=3

Each method of a bean property type is mapped to a component property. The property name is derived from the method name. Certain common property name characters, such as full stop ('.' \u002E) and hyphen-minus ('-' \u002D) are not valid in Java identifiers. So the name of a method must be converted to its corresponding property name as follows:

Table 152.2 contains some name mapping examples.

However, if the bean property type is a single-element annotation, see 9.7.3 in [16] The Java Language Specification, Java SE 8 Edition, then the property name for the value method is derived from the name of the bean property type rather than the name of the method.

In this case, the simple name of the bean property type, that is, the name of the class without any package name or outer class name, if the bean property type is an inner class, must be converted to the property name as follows:

Table 152.3 contains some mapping examples for the value method.

If the bean property type is a marker annotation, see 9.7.2 in [16] The Java Language Specification, Java SE 8 Edition, then the property name is derived from the name of the bean property type, as is described above for single-element annotations, and the value of the property is Boolean.TRUE. Marker annotations can be used to annotate component beans to set a component property to the value Boolean.TRUE. However, since marker annotations have no methods, they are of no use as injection point types.

The property type can be directly derived from the type of the method. All types supported for annotation elements can be used except for annotation types. Method types of an annotation type or array thereof are not supported.

If the method type is Class or Class[], then the property type must be String or String[], respectively, whose values are fully qualified class names in the form returned by the Class.getName() method.

If the method type is an enumeration type or an array thereof, then the property type must be String or String[], respectively, whose values are the names of the enum constants in the form returned by the Enum.name() method.

When a bean property type is used as an injection point type alone with @ComponentProperties, CCR must create a contextual instance that implements the bean property type and maps the methods of the bean property type to component properties. The name of the method is converted to the property name as described in Bean Property Type Mapping. The property value may need to be coerced to the type of the method. In Table 152.4, the columns are source types, that is, the type of the component property value, and the rows are target types, that is, the method types. The property value is v; number is a primitive numerical type and Number is a wrapper numerical type. An invalid coercion is represented by throw. Such a coercion attempt must result in throwing a Bean Property Exception when the bean property type method is called. Any other coercion error, such as parsing a non-numerical String to a number or the inability to coerce a String into a Class or enum object, must be wrapped in a Bean Property Exception and thrown when the bean property type method is called.

Component properties whose names do not map to bean property type methods are ignored. If there is no corresponding component property for a bean property type method, the bean property type method must:

Bean Property Types for standard service properties are specified in the org.osgi.service.cdi.propertytypes package.

The ServiceDescription bean property type can be used to add the service.description component property, service property or target filter. The ServiceRanking bean property type can be used to add the service.ranking component property, service property or target filter. The ServiceVendor bean property type can be used to add the service.vendor component property, service property or target filter. For example, using these Bean Property Types as annotations:

@FactoryComponent
@ServiceDescription(”My Acme Service implementation”)
@ServiceRanking(100)
@ServiceVendor("My Corp")
public class MyBean implements AcmeService {}

will result in the following component properties:

service.description=My Acme Service implementation # String
service.ranking=100 # Integer
service.vendor=My Corp # String

The ExportedService bean property type can be used to specify service properties for remote services.

Applying the @Service annotation to the bean class indicates the set of service types will be one of (in order of precedence):

The @Service annotation is never inherited. CCR ignores instances of the annotation on super classes, interfaces or super interfaces for this purpose.

A convenient readability optimization is to apply the @Service annotation on type_use. This is to say that it may be applied to extends and/or implements clauses. For example:

// service types = [BassetHound]
class Fido extends @Service BassetHound {}

Or:

// service types = [Hound]
class Fido implements @Service Hound {}

The two approaches can be combined. @Service annotations are collected so that the service is published with all collected types:

// service types = [BassetHound, Hound]
class Fido extends @Service BassetHound implements @Service Hound {}

In this scenario, any use of the @Service.value property will result in a definition error.

Applying @Service to both bean class, and type use will result in a definition error.

Applying the @Service annotation to producer methods or fields indicates the set of service types as described in the following table (earlier rows take precedence over later rows).

// service types = [BassetHound, Dog]
@Produces
@Service({BassetHound.class, Dog.class})
Spot getSpot() {
	return new Spot();
}

// service types = [Dog]
@Produces
@Service
Dog getDog() {
	return new Spot();
}

// service types = [Hound]
@Produces
@Service
Buddy getBuddy() {
	return new Buddy();
}

class Fido {}

// service types = [Fido]
@Produces
@Service
Fido getFido() {
	return new Fido();
}

// service types = [Dog]
@Produces
@Service
Dog dog = new Spot();

// service types = [Hound]
@Produces
@Service
Buddy buddy = new Buddy();

class Fido {}

// service types = [Fido]
@Produces
@Service
Fido fido = new Fido();

Regardless of the source, no service type may be a generic type. A generic type found in the set of service types will result in a definition error.

Service types must be a subset of bean types, including types restricted by the use of the @javax.enterprise.inject.Typed annotation. This restriction is required to support CDI features like Decorators and Interceptors.

Using the @Service annotation on injection points will result in a definition error.

The main source of service properties is Component Properties.

When CCR registers a service on behalf of a component instance, CCR must follow the recommendations in Property Propagation and must not propagate private configuration properties. That is, the service properties of the registered service must be all the component properties of the component configuration whose property names do not start with full stop ('.' \u002E).

Component properties whose names start with full stop are available to the component instance but are not available as service properties of the registered service.

Service scope represents the scope of the registered service object. There are three scopes supported by the OSGi Framework. Each can be represented in CCR.

Beans, producer methods and producer fields that are @ApplicationScoped result in contextual instances that are shared throughout the CDI container. Therefore they can only provide singleton scoped services. Each such case results in a single service registration. The service object is the contextual instance created by the producer or bean. However, @ApplicationScoped beans can implement org.osgi.framework.ServiceFactory or org.osgi.framework.PrototypeServiceFactory in order to provide bundle or prototype scoped service objects.

Beans, producer methods and producer fields that are @Dependent result in contextual instances which are never shared in that a new contextual instance is created for each caller. Therefore they can provide services of all scopes as outlined in Service Scope. The service object is a contextual instance created by the producer or bean on each request for a service object.

The use of @ServiceInstance on @ApplicationScoped beans will result in a definition error.

Single components can only apply the @Service annotation to beans marked with @SingleComponent.

A single component providing a service results in a single service registration.

Service objects provided by the service registration are defined by the creation of contexts. In all cases, the service object provided is the contextual instance of the bean marked @SingleComponent obtained from the context.

Factory components can only apply the @Service annotation to beans marked with @FactoryComponent.

A factory component providing a service results in one service registration for every factory configuration object associated with the factory PID of the component.

Service objects provided by the service registration are defined by the creation of contexts. In all cases, the service object provided is the contextual instance of the bean marked @FactoryComponent obtained from the context.

The Coordinator Service Specification defines a mechanism for multiple parties to collaborate on a common task without a priori knowledge of who will collaborate in that task. Like Configuration Admin Service Specification, CCR must participate in such scenarios to coordinate with provisioning or configuration tasks.

If configuration changes occur and an implicit coordination exists, CCR must delay taking action on the configuration changes until the coordination terminates, regardless of whether the coordination fails or terminates regularly.

Injection points specifying @Reference are limited to one of the following injection point types as representations of the dependent service(s). Given that type S is a type under which a service is published, the following injection point types are supported:

// S = Dog
@Inject
@Reference
Dog dog;

// S = Dog
@Inject
@Reference
ServiceReference<Dog> dog;

// S = Dog
@Inject
@Reference(Dog.class)
Map<String, Object> dogProperties;

// S = Dog
@Inject
@Reference
Map.Entry<Map<String, ?>, Dog> dog;

// S = Dog
@Inject
@Reference
BeanServiceObjects<Dog> dogs;

S must be a concrete service type. The OSGi service registry does not support generics, therefore S cannot specify a generic type.

A definition error will result if any other types are used with injection points marked @Reference unless otherwise specified by this specification.

For a bound service, CCR must get the service object from the OSGi Framework's service registry using the getService method on the component's Bundle Context. If the service object for a bound service has been obtained and the service becomes unbound, CCR must unget the service object using the ungetService method on the component's Bundle Context and discard all references to the service object. This ensures that the bundle will only be exposed to a single instance of the service object at any given time.

For a bound service of a reference where the PrototypeRequired annotation was specified, only services registered with prototype service scope can be considered as target services. This ensures that each component instance can be exposed to a single, distinct instance of the service object. Using @PrototypeRequired effectively adds service.scope=prototype to the target property of the reference. A service that does not use prototype service scope cannot be used as a bound service for a reference with @PrototypeRequired since the service cannot provide a distinct service object for each component instance.

@Inject
@PrototypeRequired
@Reference
Hound hound;

A Bean Service Objects for the bound service, can be used to obtain the actual service object or objects. This approach is useful when the referenced service has prototype service scope and the component instance needs multiple service objects for the service.

@Inject
@PrototypeRequired
@Reference
BeanServiceObjects<Hound> hounds;

The @PrototypeRequired annotation is optional. See Service Scope.

References are greedy by default which means that higher ranking matches are immediately bound. Use the @Reluctant annotation to indicate that higher ranking matches should not bind once the reference has been resolved. Note that in the case of static references the component will be destroyed and recreated in order to immediately apply the better match. In the case of the container component, this will result in the entire CDI container being destroyed and recreated.

A static, greedy reference:

@Inject
@Reference
Hound hound;

A static, reluctant reference:

@Inject
@Reluctant
@Reference
Hound hound;

As demonstrated earlier, it's possible to specify the service type of the reference by using @Reference.value() property. This supports use cases like java.util.Map<String, ?> where the service type cannot be determined.

@Inject
@Reference(Hound.class)
Map<String, Object> properties;

This makes it possible to target a more specific service type. A reference injection point whose type is Dog may target a service of type BassetHound:

@Inject
@Reference(BassetHound.class)
Dog dog;

The injection point type must be compatible with the service type. Otherwise a definition error will result.

A special exception to the service type rules is defined when the special marker type Reference.Any is set as @Reference.value. This allows for any service to match the reference. However, the following criteria must be satisfied:

Target services for a reference are constrained by the reference's service type and the target property. A default target filter can be applied by specifying @Reference.target() property.

For example, a component wants to track all Dog services that have a service property service.vendor whose value is equal to Acme, Ltd.:

@Inject
@Reference(target = "(service.vendor=Acme, Ltd.)")
Collection<Dog> dogs;

enum Tricks {
	SIT, STAND, SHAKE_PAW, TREAT_ON_NOSE
}
@Repeatable(...)
@BeanPropertyType
@interface Trick {
	Tricks value();
}

@Inject
@Reference(target = "(service.vendor=Acme Kennels, Ltd.)")
@Trick(SIT)
@Trick(TREAT_ON_NOSE)
Dog dog;

(&(trick=sit)(trick=treat_on_nose)(service.vendor=Acme Kennels, Ltd.))

The @javax.inject.Named annotation may be used to specify a name to serve as the base of the component properties used to configure the reference. If not specified the name of the reference will be derived from the fully qualified class name of the class defining the reference injection point and the reference injection point.

The production for generated names is:

name   ::= prefix '.' suffix
prefix ::= named | qname
named  ::= < @Named.value >
suffix ::= field | ctor | method
field  ::= < name of field >
ctor   ::= 'new' pIndex
method ::= mName pIndex
mName  ::= < method name >
pIndex ::= < index of @Reference parameter >

It is a definition error to have two references with the same name.

It is a definition error to specify the @javax.inject.Named annotation with no value.

In the following example the reference name is example.Fido.mate and the target and minimum cardinality properties of the reference will be example.Fido.mate.target and example.Fido.mate.cardinality.minimum respectively:

package example;

@SingleComponent
class Fido {
	@Inject
	@Reference
	Dog mate;
}

In the following example the reference name is foo and the target and minimum cardinality properties of the reference will be foo.target and foo.cardinality.minimum respectively:

package example;

@SingleComponent
class Fido {
	@Inject
	@Named("foo")
	@Reference
	Dog mate;
}

Static references are the most common form of reference injection point. Static means that their values do not change during the lifetime of the component instance which means that in order to change the service bound to the reference injection point, the entire component instance must be destroyed and recreated.

The following are more examples of static reference injection points:

@Inject
@Reference
Dog dog;

@Inject
@Reference(BassetHound.class)
Map<String, Object> props;

@Inject
void setHounds(@Reference BeanServiceObjects<Hound> hounds) {...}

@Inject
@Reference
ServiceReference<Spot> spot;

Static reference injection points are mandatory by default. They require a number of services equal to or greater than their minimum cardinality to be available in order for the component instance to resolve.

Optional reference injection points allow a component instance to become resolved when fewer matching services are found than required by the reference's minimum cardinality. The injection point type must be java.util.Optional<R> where R is one of the supported reference injection point types.

The following are examples of static optional references:

@Inject
@Reference
Optional<Dog> dog;

@Inject
@Reference(BassetHound.class)
Optional<Map<String, Object>> props;

@Inject
void setHounds(@Reference Optional<BeanServiceObjects<Hound>> hounds) {...}

@Inject
@Reference
Optional<ServiceReference<Spot>> spot;

As with other static references, static means that their values do not change during the lifetime of the component instance which means that in order to change the service bound to the reference injection point, the entire component instance must be destroyed and recreated.

Multi-cardinality references are specified using an injection point type of java.util.Collection<R>, or java.util.List<R> where R is one of the supported reference injection point types. Repeating the static examples as multi-cardinality references, we get:

@Inject
@Reference
List<Dog> dogs;

@Inject
@Reference(BassetHound.class)
Collection<Map<String, Object>> props;

@Inject
void setHounds(@Reference List<BeanServiceObjects<Hound>> hounds) {...}

@Inject
@Reference
Collection<ServiceReference<Spot>> spots;

Multi-cardinality references are naturally optional since the default value of the minimum cardinality property is 0. See Minimum Cardinality Property.

As with other static references, static means that their values do not change during the lifetime of the component instance which means that in order to change the services bound to the reference injection point, the entire component instance must be destroyed and recreated.

As stated in Minimum Cardinality Property every reference has a configurable reference property name.cardinality.minimum. However, there are cases where it is appropriate to specify a non-zero default minimum cardinality. The MinimumCardinality annotation provides this functionality.

The following is an example of setting the minimum cardinality:

@Inject
@MinimumCardinality(3)
@Reference
List<Dog> guards;

The value must be a positive integer.

Specifying this annotation on a unary reference results in a definition error.

Dynamic reference injection points are specified using an injection point type of javax.inject.Provider<R> where R is one of the supported reference injection point types, java.util.Optional<R>, java.util.Collection<R>, or java.util.List<R>.

The following are examples of dynamic references:

@Inject
@Reference
Provider<Dog> dog;

@Inject
@Reference(BassetHound.class)
Provider<Collection<Map<String, Object>>> props;

@Inject
void setHounds(
		@Reference
		Provider<List<BeanServiceObjects<Hound>>> hounds
	) {...}

@Inject
@Reference
Provider<Optional<ServiceReference<Spot>>> spots;

The evaluation of javax.inject.Provider.get() is performed such that each invocation may produce a different result except for returning null.

Specifying the @MinimumCardinality annotation with a non-zero value on a dynamic, multi-cardinality reference results in the component not being resolved until the number of matching services becomes equal to or greater than the specified minimum cardinality.

CCR must have access to the Bundle Context of any CDI bundle. CCR needs access to the Bundle Context for the following reasons:

CCR should use the Bundle.getBundleContext() method to obtain the Bundle Context reference.

The Bundle Context of the CDI bundle can be injected. The injection point must be of type org.osgi.framework.BundleContext and must not specify any qualifiers.

@Inject
BundleContext bundleContext;

When CCR is implemented as a bundle, any containers activated by CCR must be deactivated when the CCR bundle is stopped. When the CCR bundle is started, it must process the CDI metadata declared in CDI bundles. This includes bundles which are started and are awaiting lazy activation.

When CCR must log a message to the Log Service, it must use a Logger named using the component's name and associated with the CDI bundle. To obtain the Logger object, CCR must call the LoggerFactory.getLogger(Bundle bundle, String name, Class loggerType) method passing the CDI bundle as the first argument and the name of the component as the second argument. If CCR cannot know the component name, because the error is not associated with a component or the error occurred before the component template is processed, then CCR must use the bundle's Root Logger, that is, the Logger named ROOT.

A CDI bundle may also declare a Bundle Activator. Such a bundle may also be marked for lazy activation. Since CDI containers are activated by CCR and Bundle Activators are called by the OSGi Framework, a bundle using both a CDI container and a Bundle Activator must take care. The Bundle Activator's start method must not rely upon CCR having activated the bundle's CDI container. However, the CDI container can rely upon the Bundle Activator's start method having been called. That is, there is a happens-before relationship between the Bundle Activator's start method being run and the CDI container being activated.

CCR provides an introspection API for examining the runtime state of the CDI bundles processed by CCR. CCR must register a CDIComponentRuntime service upon startup. The CDI Component Runtime service provides methods to inspect CDI containers. The service uses Data Transfer Objects (DTO) as arguments and return values. The rules for Data Transfer Objects are specified in OSGi Core Release 7.

The CDI Component Runtime service provides the following methods.

The runtime state of the containers can change at any time. So any information returned by these methods only provides a snapshot of the state at the time of the method call.

There are a number of DTOs available via the CDI Component Runtime service.

Figure 152.3 CDI Component Runtime DTOs

The ContainerDTO specifies a changeCount field of type long. Whenever the DTOs bellow the ContainerDTO change, CCR will increment the ContainerDTO's changeCount. Whenever any ContainerDTO changes, CCR will update the service.changecount service property of the CDIComponentRuntime service. CCR may use a single update to the service.changecount property to reflect updates in multiple ContainerDTOs. See org.osgi.framework.Constants.SERVICE_CHANGECOUNT in OSGi Core Release 7.

CCR provides special support for logging via the Log Service specification. CCR must provide @Dependent objects of type org.osgi.service.log.Logger and org.osgi.service.log.FormatterLogger.

To obtain the Logger object for injection, CCR must call the LoggerFactory.getLogger(Bundle bundle, String name, Class loggerType) method passing the bundle declaring the component as the first argument, the fully qualified name of the injection point's declaring class as the second argument, and the type of the injection point; org.osgi.service.log.Logger or org.osgi.service.log.FormatterLogger, as the third argument. The typical usage is:

@Inject
Logger logger;

@PostConstruct
void init() {
	logger.debug("Initialized");
}

Another example using method injection along with component properties (coerced to Config):

public static @interface Config {
	String component_name();
}

@Inject
void setup(@ComponentProperties Config config, Logger logger) {
	logger.trace(“Activating component {}”, config.component_name());
}

All components in a CDI bundle are enabled by default. However, any component can be disabled through configuration using the single configuration object associated with the container PID by defining a property using the component name suffixed with .enabled. The value's type is boolean.

enabled  ::= compName '.enabled'
compName ::= < component name >

The following is an example disabling a component whose name is foo:

foo.enabled=false

The container component can be disabled using it's component name, which is the container id. As a result of disabling the container component, all components in the CDI bundle are also disabled.

There is no special support to allow service cycles within the container component. CDI provides existing mechanisms for wiring and collaborating within the CDI container. However, if an container component defines a dynamic, optional reference, then a service subsequently provided by the container component may satisfy the reference at some point when the container component is satisfied. However, if the reference is static and mandatory and the only potentially matching service is one provided by the container component itself, then the container component would wait forever for a service that will never arrive. This is simple design error. The information about unsatisfied references is available from the CDIComponentRuntime service.

The [6] Packaging and deployment chapter of the CDI specification defines XML descriptors which are used to control the CDI container. This specification expects that these descriptors be declared using the osgi.cdi extender requirement attribute descriptor of type List<String>. For example:

Require-Capability:
	osgi.extender;
		filter:=”(&(osgi.extender=osgi.cdi)(version>=1.0)(!(version>=2.0.0)))”;
		descriptor:List<String>="META-INF/beans.xml"

If the attribute is not specified the default value of META-INF/beans.xml is used.

CCR must find descriptors by calling Bundle.getResources(String) for each specified value. Note that the accepted syntax for the values is the same as for java.lang.ClassLoader.getResources. See osgi.cdi extender capability.

The CDI specification defines 3 bean discover modes which perform runtime class discovery:

This specification avoids runtime class analysis concern by ignoring the bean discovery mode specified or implied by the descriptors, requiring bean classes to be pre-calculated at build time such that the CDI container receives a concrete list of classes to process.

It is expected that the aforementioned bean discover modes be implemented in build tooling and be performed at build time.

A CDI bundle must specify the list of classes to process using the osgi.cdi extender requirement attribute beans of type List<String>. For example:

Require-Capability:
	osgi.extender;
		filter:=”(&(osgi.extender=osgi.cdi)(version>=1.0)(!(version>=2.0.0)))”;
		beans:List<String>="org.foo.Bar, org.foo.baz.Fum"

See osgi.cdi extender capability.

CDI Portable Extensions use CDI's SPI which provides a powerful mechanism for extending the base functionality of CDI. Portable extensions may add, modify or read bean and bean class metadata, define custom contexts, and much more. Through the SPI a portable extension can participate in all aspects of the CDI Container's life cycle.

Portable extensions must be provided as OSGi services using the interface javax.enterprise.inject.spi.Extension. Portable extension services must specify the service property osgi.cdi.extension whose value is a name identifying the functionality provided by the portable extension.

For example, a portable extension service that provides an implementation of the [14] Java Transaction API should specify the value of it's osgi.cdi.extension service property using the [15] Portable Java Contract name specified for it, which is JavaJTA.

Portable Extension bundles must define a capability using the namespace osgi.cdi.extension having an attribute osgi.cdi.extension whose value is the same as the name specified in the osgi.cdi.extension service property of the portable extension service. The capability must also specify a version attribute of type Version. The capability must also specify a uses directive listing all of the Java packages provided as part of the Portable Extension's API. If the portable extension implements an API specified as a Portable Java Contract the uses list should match the Portable Java Contract.

Provide-Capability:
	osgi.cdi.extension;
		osgi.cdi.extension=JavaJTA;
		version:Version="1.2";
		uses:="javax.transaction,javax.transaction.xa"
		

CDI bundles express a dependency on a portable extension by specifying a requirement in the osgi.cdi.extension namespace whose filter matches a portable extension capability. For example:

Require-Capability:
	osgi.cdi.extension;
		filter:=”(&(osgi.cdi.extension=JavaJTA)(version=1.2))”;

See osgi.cdi extender capability.

A Portable extension bundle must require the osgi.implementation capability from CCR. This requirement will wire the extension bundle to the CCR implementation and ensure that CCR is using the same javax.enterprise.* packages as the portable extension bundle.

Require-Capability:
	osgi.implementation;
		filter:="(&(osgi.implementation=osgi.cdi)(version>=1.0)(!(version>=2.0)))"

The requirement may be specified directly on any class in the portable extension bundle by using the RequireCDIImplementation annotation when the code is processed by tooling capable of interpreting Bundle Annotations defined in OSGi Core Release 7.

When the container component is satisfied CCR must published the CDI container's javax.enterprise.inject.spi.BeanManager to the service registry using the ServiceContext of the CDI bundle accompanied by the following service property:

The javax.enterprise.inject.spi.BeanManager must be unregistered when the container component becomes unsatisfied.

Decorators and Interceptors are used to wrap contextual instances with proxies to deliver additional, targeted functionality. However, these features do not support [3] unproxyable bean types. Attempting to apply either feature to a bean or producer having an unproxyable bean type will result in a definition error. This limitation extends to CCR where applicable. The @javax.enterprise.inject.Typed annotation is available to explicitly reduce the set of bean types, making it possible to use either feature on beans having unproxyable types. Implementations of this specification must support the use of @javax.enterprise.inject.Typed when publishing services.

Service objects are the product of beans and producers. As such they may be targeted by Decorators and/or Interceptors and wrapped by proxies. Therefore the subset of types under which the service is published must be a subset of the bean types, including further restrictions declared by @javax.enterprise.inject.Typed. Service types not contained in the restricted set of bean types will result in a definition error. See @Service Type Restrictions.

CCR dependencies are built upon the existing OSGi service infrastructure. This means that Service Permission applies regarding the ability to publish, find or bind services.

If a component specifies a service, that component cannot be satisfied unless the CDI bundle has ServicePermission[<provides>, REGISTER] for each provided interface specified for the service.

If a component's reference does not specify optional cardinality, the reference cannot be satisfied unless the CDI bundle has ServicePermission[<interface>, GET] for the specified interface in the reference. If the reference specifies optional cardinality but the component's bundle does not have ServicePermission[<interface>, GET] for the specified interface in the reference, no service must be bound for this reference.

CCR must have ServicePermission[CDIComponentRuntime, REGISTER] permission to register the CDIComponentRuntime service. Administrative bundles wishing to use the CDIComponentRuntime service must have ServicePermission[CDIComponentRuntime, GET] permission. In general, this permission should only be granted to administrative bundles to limit access to the potentially intrusive methods provided by this service.

CCR requires AdminPermission[*,CONTEXT] because it needs access to the CDI bundle's Bundle Context object with the Bundle.getBundleContext() method.

CCR does all publishing, finding and binding of services on behalf of the component using the Bundle Context of the CDI bundle. This means that normal stack-based permission checks will check CCR and not the component's bundle. Since CCR is registering and getting services on behalf of a CDI bundle, CCR must call the Bundle.hasPermission method to validate that a CDI bundle has the necessary permission to register or get a service.

CCR must ensure a bundle has the proper ConfigurationPermission for a Configuration used by its components when the Configuration has a multi-location. See Using Multi-Locations for more information on multi-locations and Regions for more information on regions. If a bundle does not have the necessary permission for a multi-location Configuration, then CCR must act as if the Configuration does not exist for the bundle.