Spring Interview Questions

Explain the IoC (Inversion of Control) in Spring framework?

Inversion of control is at the heart of the Spring framework. The org.springframework.beans and org.springframework.context packages provide the basis for the Spring Framework’s IoC container.
The basic concept of the Inversion of Control pattern (dependency injection) is that programmers don’t need to create your objects but describe how they should be created. In a IOC scenario, the container creates all the objects, connects them together by setting the necessary properties, and determines when methods will be invoked. The implementation pattern types for IOC used by SpringFramework are as follows:
* Dependencies can be assigned through JavaBeans properties (setter methods).
* Dependencies are provided as constructor parameters and are not exposed as JavaBeans Setter properties.

Explain the various approaches use by IoC pattern for decoupling of component in Spring framework?

The IoC (Inversion of Control) pattern uses three different approaches in order to achieve decoupling of control of services from your components:
* Interface Injection : Your components explicitly conformed to a set of interfaces, with associated configuration metadata, in order to allow the framework to manage them correctly.
* Setter Injection : External metadata is used to configure how your components can be interacted with.
* Constructor Injection : Your components are registered with the framework, including the parameters to be used when the components are constructed, and the framework provides instances of the component with all of the specified facilities applied.

What are the various steps involved in a Spring beans life cycle?

The bean factory performs several steps before a bean is ready is use:
* Instantiate.
* Populate properties.
* The factory calls BeanNameAware’s setBeanName() method.
* The factory calls BeanFactoryAware’s setBeanFactory() method.
* PostProcessBeforeInitialization() method is called if BeanPostProcessor associated with the bean.
* An init-method is called, if specified.
* Finally, PostProcessAfterInitialization() is called if BeanPostProcessor associated with it.

Explain singleton beans and how can you create prototype beans?

The singleton property of <bean> tells the context whether or not a bean is to be defined as a singleton. This attribute in bean tag named ‘singleton’ if specified true then bean becomes singleton and if set to false then the bean becomes a prototype bean. By default it is set to true. So, all the beans in spring framework are by default singleton beans.

<beans>
<bean id="bar" class="com.act.Foo" singleton=”false”/>
</beans>

Prototyped beans are useful when you want the container to give a unique instance of a bean ezch time it is asked for, but you still want to configure one or more properties  of that bean through Spring.

<bean id="student">
class="com.StudentImpl"
singleton="false">

A new instance of a prototype bean will be created each time getBean() is invoked with the bean’s name.

What is inner bean in Spring framework?

You can embed a <bean> element directly in the <property> element. For Example:


<bean id="student"
class="com.StudentImpl">
<property name="course">
<bean class="com.CourseImpl"/>
</property>
</bean>

The drawback of wiring a bean reference in this manner is that you can’t reuse the instance of StudentImpl anywhere else.

What is autowiring in the Spring framework? Explain its type?

You wire all of your bean’s properties explicitly using the <property> element, However you can have Spring wire them automatically by setting the ‘autowire’ property on each <bean> that you want autowired:

<bean id="foo"
class="com.Foo"
autowire="autowireType"/>

There are four types of autowiring:
* byName :- Attempts to find a bean in the container whose name is the same as the name of the property being wired.
* byType :- Attempts to find a single bean in the container whose type matches the type of the property being wired. If no matching bean is found, the property will not be wired.
* constructor :- Tries to match up one or more beans in the container with the parameters of one of the constructors of the bean being wired.
* autodetect :- Attempts to autowire by constructor first and then using byType. Ambiguity is handled the same way as with constructor and byType wiring.

How will you handle the ambiguities of autowiring in Spring?

When sutowiring using byType or constructor, it’s possible that the container may find two or more beans whose type matches the property’s type or the types of the constructor arguments. What will happen if there are  ambiguous beans suitable for autowiring?
Spring can’t sort out ambiguities and chooses to throw an exception raher than guess which bean you meant to wire in. If you encounter such ambiguities when autowiring, the best solution is not to autowire the bean.