Building OSGi applications using the Blueprint container specification

Brief introduction

The OSGi framework provides a good mechanism for developing modular dynamic applications, which are becoming very popular recently. The latest OSGi Service Platform Release 4 V4.2 specification includes a specification named Blueprint Container.

Spring Dynamic Module

If you are familiar with the spring framework, you will notice that there are many similarities between the spring and Blueprint Container specifications. The Blueprint specification is based exactly on the Spring Dynamic Modules project.

The Blueprint Container specification defines a dependency injection (Dependency injection) framework for OSGi. It is designed to handle the dynamic nature of OSGi, where services can become available and unavailable at any time. Another intention of the specification is to handle ordinary old Java objects (POJO) so that the same objects can be used for both the internal and external of the OSGI framework. The Blueprint XML file that defines and describes the various components of an application is important to the Blueprint programming model. The specification describes how the components are instantiated and how they are interconnected to form an application that can be run.

The Blueprint Container specification uses an Extender (extender) pattern in which the Extender Packs monitor the status of packages in the framework and perform actions on them based on their state. The Blueprint Extender package waits for the package to be activated, and then checks to see if they are Blueprint packets. If a package contains one or more Blueprint XML files, it is considered a Blueprint package. These XML files are located in a fixed location in a osgi-inf/blueprint/directory, or explicitly specified in the Bundle-blueprint list header.

Once the Extender determines that a package is a Blueprint package, it creates a Blueprint Container for the package. This Blueprint Container is responsible for doing the following:

Parsing Blueprint XML Files

Instantiation of

To connect components together

During initialization, Blueprint Container ensures that service references are enforced, registers all services in the service registry, and then creates an initial component instance. The Blueprint Extender package also destroys Blueprint Container for the package after the package has stopped.

This article will focus on Blueprint XML. Demonstrates the component XML definition and its use through several examples.

Blueprint XML

The Blueprint XML file is identified as the top-level Blueprint element, as shown in Listing 1.

Listing 1. Blueprint XML File Fragment

<?xml　version="1.0"　encoding="UTF-8"?>
<blueprint　xmlns=”http://www.osgi.org/xmlns/blueprint/v1.0.0”>
　　 ...
</blueprint>

The Blueprint XML file contains the various Component manager definitions. The Blueprint Container specification defines four main component managers: One bean manager, one service manager, and two service reference managers. Each manager is responsible for creating and managing the lifecycle of the components that are created. The manager provides a component instance. Each manager has a corresponding XML element that describes the manager attribute. The organizer can be a top-level manager or inline within another manager definition. The organizer also has some common properties.

ID of the ID definition Manager. The id attribute is an optional attribute. If not specified, a unique ID is automatically generated and assigned to the top-level manager. The inline manager is considered anonymous, so setting the id attribute is not allowed. The manager ID must be unique within the Blueprint Container for all top-level managers. The manager references each other using IDs. For example, during injection, the manager will require the referenced manager to provide an object that will be injected into the component that the manager is creating. Activation This optional property defines the activation mode for the manager. Two activation modes can be supported:

Eager, where the organizer is activated during Blueprint Container initialization.

Lazy, where the organizer activates as needed.

By default, eager activation mode is enabled. However, by setting the Default-activation property on the Blueprint element, you can modify the default activation mode for all managers within the Blueprint XML file. When the request Manager provides its first component instance, the manager is activated. When the Blueprint Container is destroyed, the manager is deactivated. Each manager has its own activation and deactivation steps. DependsOn This optional attribute specifies a list of manager IDs. The listed managers will be activated before the other manager. The organizer can have explicit or implicit dependencies. The DependsOn property defines an explicit dependency. An implicit dependency is defined in the manager definition by reference to another manager.