Spring BeanPostProcessor: instance callbacks and the early-bean trap

Operate on instances

A BeanPostProcessor can inspect or replace a freshly initialized connector. The receipt connector policy below runs after initialization and leaves the same object in the container. Unlike definition processing], this callback has an instance to inspect. Use it sparingly: ordinary validation belongs in a constructor or initialization method when only one class is affected.

Keep the processor's dependency graph small

The container creates post-processors early so they can advise later beans. If a processor injects an application service, that service can also be instantiated early and miss transaction, cache or method-security proxying. Register the processor with a static @Bean method and avoid pulling runtime services into its constructor. Proxy boundaries] already require care; early initialization can remove the proxy entirely.

Check both identity and advice

Start a context with the connector and an advised service. Verify the processor saw the connector, then call the advised service through the injected bean and assert its transaction or authorization advice still runs. A log line that says a bean was processed is not proof the rest of the application kept its proxies. If the callback wraps a bean, preserve its exposed interface and inspect identity-sensitive consumers.

Implementation contract

@Configuration
class ReceiptConnectorPolicy {
    @Bean
    static BeanPostProcessor connectorGuard() {
        return new BeanPostProcessor() {
            @Override
            public Object postProcessAfterInitialization(
                    Object candidate, String registeredName) {
                if (candidate instanceof ReceiptConnector connector) {
                    connector.verifyStartupPolicy();
                }
                return candidate;
            }
        };
    }
}

Cost and verification

A processor callback can run for many bean instances, so keep its type check and validation bounded. The larger risk is startup side effects and early dependencies that lose advice, not the nanoseconds of the instanceof test.

Common Mistakes

• Do not inject a broad service graph into an early BeanPostProcessor.
• Do not assume a post-processed bean kept every expected AOP proxy without a context test.
• Do not replace an object with a wrapper that drops its interface or lifecycle contract.

Read next

Spring BeanFactoryPostProcessor: inspect definitions before instances exist, Spring AOP proxies: self-invocation bypasses proxy advice, Spring @Configuration proxyBeanMethods: direct calls can create a second object, Spring lifecycle cleanup: close container-owned resources, Spring FactoryBean: expose the product type without constructing it.