skip to content

Name the main *Aware interfaces for injecting container infrastructure and what each hands the bean.

level: middleimportance: should knowfreq 50%

answer

  1. Name/Factory/ClassLoader = factory-level
  2. Context/Env/ResourceLoader = context-level BPP
  3. ApplicationContext is a superset
  4. narrowest interface wins
  5. ApplicationContextAwareProcessor drives group 2

basics

~10 s

BeanNameAware gives the bean name, BeanFactoryAware gives the BeanFactory, ApplicationContextAware gives the ApplicationContext, EnvironmentAware gives the Environment, and ResourceLoaderAware gives a ResourceLoader for loading files/URLs.

solid answer

~30 s

The core infrastructure-injecting Aware interfaces are: BeanNameAware (the bean's registered id), BeanFactoryAware (the owning BeanFactory for programmatic getBean lookup), BeanClassLoaderAware (the class loader), ApplicationContextAware (the full ApplicationContext — which also functions as ResourceLoader, ApplicationEventPublisher, MessageSource, and EnvironmentCapable), EnvironmentAware (the Environment: property sources plus active profiles), and ResourceLoaderAware (a ResourceLoader to obtain Resource objects for classpath:/file:/URL locations). There are also ApplicationEventPublisherAware, MessageSourceAware, and EmbeddedValueResolverAware. A key distinction: BeanNameAware, BeanClassLoaderAware, and BeanFactoryAware are wired directly by the bean factory, while ApplicationContextAware, EnvironmentAware, and ResourceLoaderAware are injected by a BeanPostProcessor that only an ApplicationContext registers.

code

java · 21 lines
java
import org.springframework.context.EnvironmentAware;
import org.springframework.context.ResourceLoaderAware;
import org.springframework.core.env.Environment;
import org.springframework.core.io.Resource;
import org.springframework.core.io.ResourceLoader;
import org.springframework.stereotype.Component;

@Component
public class ReportLoader implements EnvironmentAware, ResourceLoaderAware {

    private Environment env;
    private ResourceLoader resourceLoader;

    @Override public void setEnvironment(Environment e) { this.env = e; }
    @Override public void setResourceLoader(ResourceLoader rl) { this.resourceLoader = rl; }

    public Resource template() {
        String location = env.getProperty("report.template", "classpath:default.html");
        return resourceLoader.getResource(location); // both injected by ApplicationContextAwareProcessor
    }
}

go deeper

for a junior

Be able to list a few Aware interfaces and what each provides.

for a middle

Know the full common set and that ApplicationContext is a superset of ResourceLoader/EventPublisher/MessageSource/Environment.

for a senior

Articulate the factory-level vs context-level split and which processor drives each.

for a principal

Advise on narrowest-interface selection and coupling minimization across a codebase.

## The catalog Spring exposes a small family of `*Aware` callback interfaces, each handing a bean one piece of the container's infrastructure. Grouped by what they inject: | Interface | Setter | What it provides | |---|---|---| | `BeanNameAware` | `setBeanName(String)` | The id/name under which the bean is registered. | | `BeanFactoryAware` | `setBeanFactory(BeanFactory)` | The owning low-level container; enables `getBean(...)` lookups. | | `BeanClassLoaderAware` | `setBeanClassLoader(ClassLoader)` | The class loader used to load bean classes. | | `ApplicationContextAware` | `setApplicationContext(ApplicationContext)` | The full application container. | | `EnvironmentAware` | `setEnvironment(Environment)` | Property sources + active/default profiles. | | `ResourceLoaderAware` | `setResourceLoader(ResourceLoader)` | A loader for `Resource` objects. | | `ApplicationEventPublisherAware` | `setApplicationEventPublisher(...)` | Publisher to fire application events. | | `MessageSourceAware` | `setMessageSource(MessageSource)` | i18n message resolution. | | `EmbeddedValueResolverAware` | `setEmbeddedValueResolver(StringValueResolver)` | Resolves `${...}` / `#{...}` in strings. | ## The two-tier distinction (important) The interfaces split into two groups by **who invokes them**: 1. **BeanFactory-level**: `BeanNameAware`, `BeanClassLoaderAware`, `BeanFactoryAware`. These are invoked directly inside `AbstractAutowireCapableBeanFactory.invokeAwareMethods(...)`, which every `BeanFactory` runs. They work even in a bare `DefaultListableBeanFactory` with no `ApplicationContext`. 2. **ApplicationContext-level**: `ApplicationContextAware`, `EnvironmentAware`, `ResourceLoaderAware`, `ApplicationEventPublisherAware`, `MessageSourceAware`, `EmbeddedValueResolverAware`, `ApplicationStartupAware`. These are invoked by the `ApplicationContextAwareProcessor`, a `BeanPostProcessor` that only an `ApplicationContext` registers (in `AbstractApplicationContext.prepareBeanFactory`). **In a plain BeanFactory these callbacks never fire.** ## ApplicationContext is a superset Because `ApplicationContext extends ResourceLoader, ApplicationEventPublisher, MessageSource, EnvironmentCapable`, implementing `ApplicationContextAware` alone effectively gives access to everything the finer-grained Aware interfaces offer. That is convenient but is the heaviest possible coupling — prefer the narrowest interface (or plain DI) that meets the need. ## Term definitions - **`BeanFactory`**: the fundamental container that instantiates and wires beans. - **`ApplicationContext`**: enterprise-grade container built on `BeanFactory`, adding events, i18n, resource loading, environment. - **`Environment`**: abstraction over configuration (property sources) and profiles. - **`ResourceLoader`**: turns location strings (`classpath:app.txt`, `file:/etc/x`) into `Resource` handles. ## When to use which Reach for the **narrowest** interface. Need to load a bundled file? `ResourceLoaderAware`. Need a profile or property? `EnvironmentAware` (or better, `@Value` / `Environment` injection). Need to look up a prototype on demand? `BeanFactoryAware` (or an `ObjectProvider`/lookup method). Avoid `ApplicationContextAware` unless you truly need multiple context facets, since it is the strongest coupling.

  • If a bean only needs the Environment, is ApplicationContextAware or EnvironmentAware the better choice?
    EnvironmentAware — it is the narrowest interface. Even better, inject Environment directly or use @Value, avoiding framework coupling entirely.
  • Does implementing ApplicationContextAware give access to event publishing and resource loading too?
    Yes, because ApplicationContext also implements ApplicationEventPublisher, ResourceLoader, MessageSource, and EnvironmentCapable — but that is the heaviest coupling and generally discouraged.

context

resolving links…