Spring BeanPostProcessor

A `BeanPostProcessor` lets Spring intercept bean instances during creation and initialization. It can inspect, modify, replace, or wrap a bean before and after its initialization callbacks run.

A `BeanPostProcessor` is a Spring extension point that participates in the lifecycle of beans managed by an `ApplicationContext`. Spring invokes registered processors around bean initialization, giving them an opportunity to transform the object that will ultimately be exposed as the bean.

The central methods are `postProcessBeforeInitialization` and `postProcessAfterInitialization`. The first runs before configured initialization callbacks such as `@PostConstruct`; the second runs after those initialization callbacks. Either method can return the original object or another object, such as a proxy.

Bean post-processors are commonly used for cross-cutting infrastructure. Spring features such as dependency injection, annotation processing, and proxy-based facilities rely on this general lifecycle mechanism. A processor can therefore affect many beans without requiring each bean class to implement special interfaces.

A key distinction is that a `BeanPostProcessor` operates on individual bean instances, while a `BeanFactoryPostProcessor` changes bean-definition metadata before bean instances are created. Also, returning `null` from a post-processing method has special lifecycle semantics and should not be done casually.

Key points

• `postProcessBeforeInitialization` runs before initialization callbacks.
• `postProcessAfterInitialization` runs after initialization callbacks.
• A processor may return the same bean or a replacement such as a proxy.
• BPPs operate on bean instances; `BeanFactoryPostProcessor` operates on bean definitions.
• They are infrastructure used by Spring for lifecycle and cross-cutting behavior.

Interview questions

What is a `BeanPostProcessor` and when is it used?

A `BeanPostProcessor` is a Spring extension point for intercepting bean instances during initialization. Spring calls its before- and after-initialization methods for eligible beans. A processor can inspect the bean, mutate it, or return another object such as a proxy. It is useful for framework infrastructure and cross-cutting behavior that should apply across multiple beans.

What is the difference between `postProcessBeforeInitialization` and `postProcessAfterInitialization`?

The before method is invoked before Spring executes the bean's initialization callbacks. The after method runs after those callbacks have completed. Both can return the same object or another object. This distinction matters when a processor needs to observe or alter the bean before initialization versus when it needs the fully initialized instance.

Can a `BeanPostProcessor` return a proxy?

Yes. A post-processor can return a proxy instead of the original bean instance, so later consumers receive the proxy as the exposed bean. This is a common mechanism for adding behavior such as method interception. Spring's proxy-based infrastructure uses bean post-processing as part of this general pattern.

How does `BeanPostProcessor` differ from `BeanFactoryPostProcessor`?

A `BeanFactoryPostProcessor` works with bean definitions, before the corresponding bean instances are normally created. A `BeanPostProcessor` works with actual bean objects during their lifecycle. The first is appropriate for changing metadata such as definition properties, while the second is appropriate for changing or wrapping instantiated objects.

Does a `BeanPostProcessor` process objects created with `new`?

No. A `BeanPostProcessor` is part of the Spring container's bean lifecycle. An object created directly with `new` outside that lifecycle is not automatically passed through the container's post-processors. To receive this processing, the object generally needs to be created and managed as a Spring bean.