Ce contenu n'est pas disponible dans la langue sélectionnée.
1.3. Dependency Injection Frameworks
Dependency injection
Dependency injection or inversion of control (IOC) is a design paradigm for initializing and configuring applications. Instead of writing Java code that explicitly finds and sets the properties and attributes required by an object, you declare setter methods for all of the properties and objects that this object depends on. The framework takes responsibility for injecting dependencies and properties into the object, using the declared setter methods. This approach reduces dependencies between components and reduces the amount of code that must be devoted to retrieving configuration properties.
There are many popular dependency injection frameworks in current use. In particular, the Spring framework and the blueprint framework are fully integrated with Red Hat JBoss Fuse.
OSGi framework extensions
One of the important characteristics of the OSGi framework is that it is extensible. OSGi provides a framework extension API, which makes it possible to implement OSGi plug-ins that are tightly integrated with the OSGi core. An OSGi extension can be deployed into the OSGi container as an extension bundle, which is a special kind of bundle that enjoys privileged access to the OSGi core framework.
Red Hat JBoss Fuse defines extension bundles to integrate the following dependency injection frameworks with OSGi:
- Blueprint—the blueprint extensor is based on the blueprint implementation from Apache Karaf.
- Spring—the Spring extensor is based on Spring Dynamic Modules (Spring-DM), which is the OSGi integration component from SpringSource.NoteThe Spring-DM module is now deprecated. If you need an injection framework with OSGi integration, use Blueprint instead.
Activating a framework
The framework extension mechanism enables both the Spring extensor and the blueprint extensor to be integrated with the bundle lifecycle. In particular, the extenders receive notifications whenever a bundle is activated (using the command,
osgi:start) or de-activated (using the command, osgi:stop). This gives the extenders a chance to scan the bundle, look for configuration files of the appropriate type and, if necessary, activate the dependency injection framework for that bundle.
For example, when we use Spring configuration, the spring extensor scans the bundle package, looking for any blueprint XML files in the standard location and, if it finds one or more such files, it activates the blueprint framework for this bundle.
Blueprint XML file location
The blueprint extensor searches a bundle for blueprint XML files whose location matches the following pattern:
OSGI-INF/blueprint/*.xml
Note
A blueprint XML file can also be placed in a non-standard location, by specifying the location in a bundle header (see the section called “Custom Blueprint file locations”).
Spring XML file location
The Spring extensor searches a bundle for Spring XML files whose location matches the following pattern:
META-INF/spring/*.xml
Note
A WAR package uses a different mechanism to specify the location of Spring XML files (see Section 11.3, “Bootstrapping a Spring Context in a WAR”).
