1.3. Dependency Injection Frameworks


Revision History
09/27/12
Reordered to make blueprint more prominent

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.

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 you activate a bundle that is configured using Spring, the blueprint extensor scans the bundle package, looking for any blueprint XML files in the standard location and, if it finds one or more such files, 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”).
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.