搜索

此内容没有您所选择的语言版本。

1.3. Dependency Injection Frameworks

download PDF

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.
    Note
    The 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”).
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.