Bean - abhishekkhare/SpringCore GitHub Wiki

The objects that form the backbone of your application and that are managed by the Spring IoC container are called beans. A bean is an object that is instantiated, assembled, and otherwise managed by a Spring IoC container. These beans are created with the configuration metadata that you supply to the container.

The bean definition contains the information called configuration metadata which is needed for the container to know the followings:

• How to create a bean
• Bean's lifecycle details
• Bean's dependencies

All the above configuration metadata translates into a set of the following properties that make up each bean definition.

• class - This attribute is mandatory and specify the bean class to be used to create the bean.
• name - This attribute specifies the bean identifier uniquely. In XML-based configuration metadata, you use the id and/or name attributes to specify the bean identifier(s).
• scope - This attribute specifies the scope of the objects created from a particular bean definition.
• constructor-arg - This is used to inject the dependencies.
• properties - This is used to inject the dependencies
• autowiring mode- This is used to inject the dependencies
• lazy-initialization mode - A lazy-initialized bean tells the IoC container to create a bean instance when it is first requested, rather than at startup.
• initialization method - A callback to be called just after all necessary properties on the bean have been set by the container.
• destruction method - A callback to be used when the container containing the bean is destroyed.

When defining a in Spring, you have the option of declaring a scope for that bean. For example, To force Spring to produce a new bean instance each time one is needed, you should declare the bean's scope attribute to be prototype. Similar way if you want Spring to return the same bean instance each time one is needed, you should declare the bean's scope attribute to be singleton.

The Spring Framework supports following five scopes, three of which are available only if you use a web-aware ApplicationContext.

• singleton This scopes the bean definition to a single instance per Spring IoC container (default).
• prototype This scopes a single bean definition to have any number of object instances.
• request This scopes a bean definition to an HTTP request. Only valid in the context of a web-aware Spring ApplicationContext.
• session This scopes a bean definition to an HTTP session. Only valid in the context of a web-aware Spring ApplicationContext.
• global-session This scopes a bean definition to a global HTTP session. Only valid in the context of a web-aware Spring ApplicationContext.

The singleton scope: If scope is set to singleton, the Spring IoC container creates exactly one instance of the object defined by that bean definition. This single instance is stored in a cache of such singleton beans, and all subsequent requests and references for that named bean return the cached object.The default scope is always singleton however, when you need one and only one instance of a bean, you can set the scope property to singleton in the bean configuration file

The prototype scope: If scope is set to prototype, the Spring IoC container creates new bean instance of the object every time a request for that specific bean is made. As a rule, use the prototype scope for all state-full beans and the singleton scope for stateless beans.To define a prototype scope, you can set the scope property to prototype in the bean configuration file.

The life cycle of a Spring bean is easy to understand. When a bean is instantiated, it may be required to perform some initialization to get it into a usable state. Similarly, when the bean is no longer required and is removed from the container, some cleanup may be required. To define setup and teardown for a bean, we simply declare the with init-method and/or destroy-method parameters. The init-method attribute specifies a method that is to be called on the bean immediately upon instantiation. Similarly, destroy-method specifies a method that is called just before a bean is removed from the container.

The BeanPostProcessor interface defines callback methods that you can implement to provide your own instantiation logic, dependency-resolution logic etc. You can also implement some custom logic after the Spring container finishes instantiating, configuring, and initializing a bean by plugging in one or more BeanPostProcessor implementations.

You can configure multiple BeanPostProcessor interfaces and you can control the order in which these BeanPostProcessor interfaces execute by setting the order property provided the BeanPostProcessor implements the Ordered interface.

The BeanPostProcessors operate on bean (or object) instances which means that the Spring IoC container instantiates a bean instance and then BeanPostProcessor interfaces do their work.

An ApplicationContext automatically detects any beans that are defined with implementation of the BeanPostProcessor interface and registers these beans as post-processors, to be then called appropriately by the container upon bean creation.