Concept of Beans in 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“. This is the seventh post of the series. This post is dedicated for briefly introducing the concept of beans in Spring and related component to you. This is intentionally put here so that when I refer them in some detailed discussion, you will find it easy to co-relate. Of course we will discuss these components in length and breadth once again, as we move forward.

Concept of Beans in Spring

Beans in Spring adhere to the standards of Java Beans. A Java Bean is simply a class with a no argument constructor, which follows a naming convention for its properties and their setters and getters.

For e.g. if there exists a property age then the setter must be named setAge() and the getter must be named as getAge().

Beans are the building block of any Spring Application. In fact everything in Spring is a Bean. A Spring bean is just a plain old Java object. Any Java class qualifies to be a Spring Bean in particular.  There are several beans in the application and they are somehow wired together to behave as one unit to accomplish the application behavior.

While writing a Spring application, these beans have to be defined beforehand by providing a bean metadata which is contained in a configuration metadata. For visualization and better understanding, you can consider the configuration metadata to be a file and bean metadata to be individual entries in the file.

Bean Definition

When a Spring application is bootstrapped by the JVM, the configuration metadata is read and an in-memory model is prepared for the configuration metadata. For each bean metadata which is read from the configuration, a separate instance of BeanDefinition is created.

The BeanDefinition describes a bean instance which has property values, constructor argument values, dependencies, scope information, bean name, bean description, initialization method, destruction method and other information which can aid in creation of a bean in a usable state.

Simply put, the bean definition is used as a recipe to instantiate actual beans in the application at run time. All the beans in the application are created and instantiated using their BeanDefinition objects.  Each of these BeanDefinition instances are stored in a BeanDefinitionRegistry and the BeanDefinitionRegistry is stored into a BeanFactory.

Bean Factory

A BeanFactory can be considered as a partial representation of the configuration metadata. It is responsible for loading the bean metadata and for creating bean definitions out of them. The BeanFactory is responsible for returning a usable bean instance, given a bean name. It can also return a list off usable bean instances given a type as there can be more than one bean of a given type. It is also capable of answering basic questions about a bean. For e.g.:

  • If the bean is contained in the factory?
  • If the bean is of a given type?
  • What are the aliases of the bean?
  • What is the type of the bean?
  • What is the 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 or collaborating beans.

Application Context

We have reached far enough and have acquired good knowledge to understand the concept of the Application Context. It is a special kind of BeanFactory.

Question: What does this mean and why do we need a specialized version of BeanFactory if we are getting all the dependency injection using the BeanFactory we already have?

Answer: Although we agree that an application is mostly about beans collaborating with each other to accomplish a bigger task. But apart from these collaborations there are few more functional requirements of an application. For e.g.

  • All applications need to deal with properties files and inject properties and other environment information into beans.
  • All applications need to deal with message bundle and I18n features.
  • All applications need to deal with static and dynamic resources (like images, URLs etc.)
  • Most of the applications need to publish various kinds of application events to other collaborating beans and external objects.
  • And of course applications need collaborating beans.

The BeanFactory is only capable of addressing the last point, whereas the ApplicationContext provides first hand support for all the above points.


Note that this post is just an introduction to the major concepts in Spring and making you familiar to the terminologies. The most important of them is the BeanFactory and ApplicationContext. In the next post, we will try to understand the concepts of Bean Life Cycle and Post Processors. Stay Connected.