Weld-OSGi is composed of five bundles:

Note that as Weld-OSGi runs in an OSGi environment and it is implicit that there is an OSGi core bundle too. This one provides OSGi features for all other bundles, including bean bundles. But it is not an actual part of Weld-OSGi.

This figure shows the five bundles of Weld-OSGi and the links between them.

Figure 1.1. The five bundles of Weld-OSGi

As an extension to OSGi, Weld-OSGi provides several features :

This section presents the lifecycle of a bean bundle and how it impacts CDI and OSGi regular behaviors. Mostly bean bundles follow the same lifecycle than a regular bundle. There are only two new possible states and they do not modify the behavior from OSGi side.

This figure shows the two new states a bean bundle can be in. These states are triggered by two new events and address the CDI container dependency resolution (i.e. services annotated @Required).

Figure 6.1. The bean bundle lifecycle

There are very few things to do in order to obtain a bean bundle from a bean archive or a bundle. Mostly it is just adding the missing marker files and headers in the archive:

Thus a bean bundle has both META-INF/bean.xml file and OSGi marker headers in its META-INF/Manifest.MF file.

However there is a few other information that Weld-OSGi might need in order to perform a correct extension. In particular a bean bundle can not be manage by the extension bundle but by his own embedded CDI container. For that there is a new manifest header.

Weld-OSGi detects a bundle as a bean bundle if:

The managed set of bean classes of a bean class contains all the class file under all META-INF/beans.xml root paths.

CDI and Weld-OSGi features are enabled for all these manageable paths.

Everything possible in CDI application is possible in bean bundle. They can take advantage of injection, producers, interceptors, decorators and alternative. But influence boundary of the CDI compliant container stay within the bean bundle managed paths for classic CDI usages. So external dependencies cannot be injected and interceptor, decorator or alternative of another bean bundle cannot be used (yet interceptors, decorators and alternatives still need to be declares in the bean bundle bean.xml file).

That is all we will say about classic CDI usages, please report to CDI documentation for more information.

Weld-OSGi provides numerous events about OSGi events and bean bundle lifecycle events. It also allows decoupled bean bundle communication.

All these features uses CDI events mechanisms:

public void bindBundle(@Observes @BundleName("com.sample.gui") @BundleVersion("4.2.1") AbstractBundleEvent event) {
}
public void bindBundle(@Observes @BundleName("com.sample.gui") BundleInstalled event) {
}

public void bindService(@Observes @Specification(MyService.class) AbstractServiceEvent event) {
}
public void bindService(@Observes @AnyQualifier ServiceArrival event) {
}
public void bindService(@Observes @Specification(MyService.class) @Filter("(&(lang=EN)(country=US))") ServiceChanged event) {
}

public void listenAllEventsFromOtherBundles(@Observes @Sent InterBundleEvent event) {
}
public void listenMyMessageEvents(@Observes @Specification(MyMessage.class) InterBundleEvent event) {
}
public void listenMyMessageEventsFromOtherBundles(@Observes @Sent @Specification(MyMessage.class) InterBundleEvent event) {
}