Description

I’m working on a project where we maintain a custom IoC container alongside the Spring ApplicationContext. We want Spring’s dependency injection to:

First try to resolve beans from its own ApplicationContext

If not found, dynamically fallback to our custom container — without pre-registering all custom beans into Spring

Currently, Spring throws NoSuchBeanDefinitionException when a required bean is missing, and no out-of-the-box extension point allows fallback lookup into external containers.

Use Cases

Applications maintaining multiple IoC containers for legacy or architectural reasons

Using external container beans only if Spring context doesn’t have them

Avoid premature registration or duplication of beans in Spring

Enable lazy, on-demand integration of external beans to reduce startup time and resource consumption

Proposed Feature

Provide a pluggable extension point (e.g., a fallback BeanFactory or BeanResolver chain) for bean resolution

Allow Spring to delegate bean lookups that fail locally to external containers

Support fallback during autowiring, lookup by name, and via ObjectProvider

Seamless integration with Spring Boot’s auto-configuration and lifecycle management

Benefits

Increased flexibility to coexist with other IoC containers

Supports hybrid container architectures without heavy customization

Reduces complexity and boilerplate for dynamic bean resolution scenarios

Thanks for your consideration and for maintaining such a powerful framework!

Comment From: jhoeller

Generally, speaking, a Spring BeanFactory is meant to be self-contained in terms of managing all of its beans consistently. By design, it does not provide a general hook to bring in an arbitrary set of external beans to manage.

That said, for a delegation arrangement, we have the "parent" concept: setParentBeanFactory allows you to set a custom BeanFactory implementation with such external lookups there, also on a DefaultListableBeanFactory inside a managed ApplicationContext. This should also work fine in Spring Boot as long as there is no pre-configured parent context which tries to set the parent factory itself. Could that work for your purposes?

Comment From: HuangDayu

After setting setParentBeanFactory, if there are beans with the same name or type, which BeanFactory has a higher priority for beans? I will try this method to see if it can solve my problem.

Comment From: HuangDayu

How can I implement a custom BeaFactory that inherits from the DefaultListableBeanFactory, and which methods should I override? getBean(Class<T> requiredType) and getBean(Class<T> requiredType, Object... args) ?

Comment From: jhoeller

The local BeanFactory has priority over a parent BeanFactory. If dependency resolution cannot find a matching bean in the local factory, it will ask the parent.

In terms of implementation, you don't need to inherit from DefaultListableBeanFactory unless you need another self-contained factory (with local bean definition management and local singleton instance management). Feel free to implement the plain BeanFactory interface with just getBean, getType etc delegating to your custom container without much local state at all, possibly reusing bits and pieces from the DefaultListableBeanFactory implementation.

Comment From: HuangDayu

Thank you, this method has solved my problem. Will we still consider support for bean lookup fallback to external containers? This may be a feasible solution to consider.

Thank you very much for your help. good luck.