Understanding the BeanFactory – Spring


This is a series and it would make a lot of sense if read in a sequence. You can find all the posts under the heading “Spring Beginners to Professionals“. In the previous post we mentioned about the BeanFactory. Here we will try and put some more effort in understanding the BeanFactory. A deeper understanding of the BeanFactory will ease our journey further.

Understanding the BeanFactory

As our XML configuration metadata is a container of bean elements, so is our BeanFactory a container of BeanDefinitions and in turn beans. We can consider the BeanFactory as a central registry which centralizes configuration of application components.

The bean factory is responsible for loading the bean definitions from the bean metadata stored in a configuration file.  It is responsible for returning a bean instance given a bean name, it can also return a list of bean instances given a Type. It is also responsible for answering basic question about a given bean like

  • Is the bean contained in the factory?
  • What are the aliases of the bean?
  • Type of the bean?
  • Scope of the bean?

Bean Factory is often termed as the IoC container because they act as a holder of the beans and help in wiring collaborating beans. Spring offers different sub interfaces of the BeanFactory interface for different needs. The most important ones are the ListableBeanFactory and HierarchicalBeanFactory.


The ListableBeanFactory enumerates all the beans in the factory. This is of great help when you want to get all the beans in the application at once. When you do not need to query the beans one by one based on their names. The bean factories which prefer pre-loading of all the bean definitions generally implement this interface. For e.g. the XML based factories.

It only lists the beans defined in the this factory, which can be considered as a drawback. If this factory lies in any hierarchy, it won’t return the beans in the hierarchy in the list of beans returned as a result of invocation of getBeanDefinitionNames() or getBeanDefinitionCount()


The HeirarchicalBeanFactory supports hierarchy of bean factories. While creating such a bean factory, you can supply a parent bean factory.

Why is hierarchical bean factory even required?

Frankly speaking, you will seldom use bean factories in normal scenarios, people mostly use ApplicationContext which is a sub interface of the both the bean factories. We will discuss the ApplicationContext in length and breadth in next post.

But as this series is not about a toy project, I am sure everyone of you will get a chance to work with big enterprise projects. When we deal with such projects we need to understand the importance of various bean factories and the hierarchies.

Consider an enterprise web application bundled as an ear package. Also assume that the package internally contains several modules bundled as wars and few jars. If there are few core beans which you expect to be available in all the modules then it would be a good idea to create a parent application context and put all these classes in that context.

Each war can be now packaged as a separate web module and can have its own web application context. While creating this application context, we can supply the parent application context. That would establish a hierarchy between both the contexts.

The biggest benefits of this approach is that the beans in parent context are not instantiated per application context.

A practical example

Consider a scenario where you have to interact with a database using any of the existing ORMs, let say hibernate and you need a SessionFactory object. As creating a session factory is a costly affair, you definitely won’t instantiate it in all the modules, but just create it in a parent context and let the context supply the SessionFactory to the chain of hierarchies.

A word of caution from Spring community “Do not invoke the methods of this interface frequently as they can be slow”

The post focused on understanding the BeanFactory and tried to explain its importance. We also discussed about the ListableBeanFactory and HierarchicalBeanFactory specializations. However, I mentioned that in real use cases, you will mostly use ApplicationContext and its specialization. We will discuss about the ApplicationContext in detail in the next post.