1.6.2. ApplicationContextAware and BeanNameAware
1.6.2. ApplicationContextAware 和 BeanNameAware
When an ApplicationContext creates an object instance that implements the org.springframework.context.ApplicationContextAware interface, the instance is provided with a reference to that ApplicationContext. The following listing shows the definition of the ApplicationContextAware interface:
当 ApplicationContext 创建一个实现 org.springframework.context.ApplicationContextAware 接口的对象实例时,会为该实例提供对该 ApplicationContext 的引用。 以下清单显示了 ApplicationContextAware 接口的定义:
public interface ApplicationContextAware {
void setApplicationContext(ApplicationContext applicationContext) throws BeansException;
}
Thus, beans can programmatically manipulate the ApplicationContext that created them, through the ApplicationContext interface or by casting the reference to a known subclass of this interface (such as ConfigurableApplicationContext, which exposes additional functionality). One use would be the programmatic retrieval of other beans. Sometimes this capability is useful. However, in general, you should avoid it, because it couples the code to Spring and does not follow the Inversion of Control style, where collaborators are provided to beans as properties. Other methods of the ApplicationContext provide access to file resources, publishing application events, and accessing a MessageSource. These additional features are described in Additional Capabilities of the ApplicationContext.
因此,bean 可以通过 ApplicationContext 接口或通过将引用转换为该接口的已知子类(例如 ConfigurableApplicationContext,它公开附加功能)以编程方式操作创建它们的 ApplicationContext。一种用途是对其他 bean 进行编程检索。有时,此功能很有用。但是,一般情况下,您应该避免使用它,因为它将代码与 Spring 耦合,并且不遵循 Inversion of Control 样式,其中协作者作为属性提供给 bean。 ApplicationContext 的其他方法提供对文件资源的访问、发布应用程序事件和访问 MessageSource。这些附加功能在 ApplicationContext 的附加功能中进行了描述。
As of Spring 2.5, autowiring is another alternative to obtain a reference to the ApplicationContext. The “traditional” constructor and byType autowiring modes (as described in Autowiring Collaborators) can provide a dependency of type ApplicationContext for a constructor argument or a setter method parameter, respectively. For more flexibility, including the ability to autowire fields and multiple parameter methods, use the new annotation-based autowiring features. If you do, the ApplicationContext is autowired into a field, constructor argument, or method parameter that expects the ApplicationContext type if the field, constructor, or method in question carries the @Autowired annotation. For more information, see Using @Autowired.
从 Spring 2.5 开始,自动装配是获取 ApplicationContext 引用的另一种方法。 “传统”构造函数和 byType 自动装配模式(如 Autowiring Collaborators 中所述)可以分别为构造函数参数或 setter 方法参数提供 ApplicationContext 类型的依赖关系。要获得更大的灵活性,包括自动装配字段和多个参数方法的能力,请使用新的基于注释的自动装配功能。如果这样做,ApplicationContext 将自动装配到需要 ApplicationContext 类型的字段、构造函数参数或方法参数中,前提是相关字段、构造函数或方法带有 @Autowired 注释。有关更多信息,请参阅使用 @Autowired。
When an ApplicationContext creates a class that implements the org.springframework.beans.factory.BeanNameAware interface, the class is provided with a reference to the name defined in its associated object definition. The following listing shows the definition of the BeanNameAware interface:
当 ApplicationContext 创建一个实现 org.springframework.beans.factory.BeanNameAware 接口的类时,该类将提供对其关联对象定义中定义的名称的引用。以下清单显示了 BeanNameAware 接口的定义:
public interface BeanNameAware {
void setBeanName(String name) throws BeansException;
}
The callback is invoked after population of normal bean properties but before an initialization callback such as InitializingBean.afterPropertiesSet, or a custom init-method.
在填充正常的bean属性之后,但在初始化回调(例如InitializingBean.afterPropertiesSet或自定义init-method)之前,调用该回调。
1.6.3. Other Aware Interfaces
1.6.3. 其他感知接口
Besides ApplicationContextAware and BeanNameAware (discussed earlier), Spring offers a range of Aware interfaces that let beans indicate to the container that they require a certain infrastructure dependency. As a general rule, the name is a good indication of the dependency type. The following table summarizes the most important Aware interfaces:
除了ApplicationContextAware和BeanNameAware(前面已经讨论过)之外,Spring还提供了多种Aware回调接口,这些接口使Bean向容器指示它们需要某种基础结构依赖性。 通常,名称表示依赖项类型。 下表总结了最重要的Aware接口:
Table 4. Aware interfaces
表4.感知接口
Name | Injected Dependency | Explained in… |
---|---|---|
ApplicationContextAware | Declaring ApplicationContext | ApplicationContextAware and BeanNameAware |
ApplicationEventPublisherAware | Event publisher of the enclosing ApplicationContext. | Additional Capabilities of the ApplicationContext |
BeanClassLoaderAware | Class loader used to load the bean classes. | Instantiating Beans |
BeanFactoryAware | Declaring BeanFactory. | The BeanFactory |
BeanNameAware | Name of the declaring bean. | ApplicationContextAware and BeanNameAware |
LoadTimeWeaverAware | Defined weaver for processing class definition at load time. | Load-time Weaving with AspectJ in the Spring Framework |
MessageSourceAware | Configured strategy for resolving messages (with support for parametrization and internationalization). | Additional Capabilities of the ApplicationContext |
NotificationPublisherAware | Spring JMX notification publisher. | Notifications |
ResourceLoaderAware | Configured loader for low-level access to resources. | Resources |
ServletConfigAware | Current ServletConfig the container runs in. Valid only in a web-aware Spring ApplicationContext. | Spring MVC |
ServletContextAware | Current ServletContext the container runs in. Valid only in a web-aware Spring ApplicationContext. | Spring MVC |
Note again that using these interfaces ties your code to the Spring API and does not follow the Inversion of Control style. As a result, we recommend them for infrastructure beans that require programmatic access to the container.
再次注意,使用这些接口会将您的代码与Spring API绑定在一起,并且不遵循“控制反转”样式。 因此,我们建议将它们用于需要以编