The bean configuration information is stored in an XML file, which is used to create a bean definition using the <bean>...</bean> element. The bean definition contains the following metadata, which represents the configuration information of a bean:

The following code snippet shows the basic structure of the XML configuration of the metadata:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.springframework.org/schema/beans
   http://www.springframework.org/schema/beans/spring-beans.xsd">

   <bean id="..." class="...">
         <!-- configuration for this bean here -->
   </bean>
   <!-- more bean definitions here -->

</beans>

The configuration files have <beans> as the root element. The beans element has all other individual beans configured using the <bean> tag. Every <bean> tag needs to specify a class attribute and can have an optional ID or name attribute. The ID attributes enforce uniqueness in naming the beans. The class attribute has the fully classified class name; for example, the src.org.packt.Spring.chapter2.Employee class can be configured as follows:

...
<bean id="employeeBean"
         class="src.org.packt.Spring.chapter2.Employee">
   </bean>
   ...

A reference of the Employee class instance is returned when the configuration file is loaded using the BeanFactory or ApplicationContext container, and employeeBean is accessed using the getBean (employeeBean) method. The Spring IoC container is responsible for instantiating, configuring, and retrieving your Spring beans. The Spring IoC container enforces DI in its various forms and employs a number of established design patterns to achieve this.

Spring provides the following two interfaces that act as containers:

To instantiate Spring Container, create an object of any of the BeanFactory or ApplicationContext implementation classes that supply the Spring bean configuration. The basic packages in the Spring IoC container of the Spring Framework are org.springframework.beans and org.springframework.context. An advanced configuration mechanism is provided by the BeanFactory interface to manage any type of object. The ApplicationContext interface implements the BeanFactory interface, which provides enterprise-specific functionality and supports message-resource handling, Spring's AOP features, event publication, and WebApplicationContext for use in web applications.

Both the containers, BeanFactory and ApplicationContext, are responsible for providing DI. For all the configured beans, these containers act as a repository. These containers initiate a registered bean, populate the bean's properties, and call the init() method to make the bean ready for use. The destroy() method of bean is invoked during the shutdown of the application. The init() and destroy() methods reflect the Servlet life cycle, where initialization can be performed during the init() method and cleanup during the destroy() method.

In a factory pattern, we have an object that behaves as the object factory. Basically, if you need an instance of any object, you don't have to create the instance yourself. Instead, you call a method of this factory, which then returns the instance you wanted. This factory reads from a configuration file, which acts as a blueprint that contains guidelines on how we can create the object.

Assume that we have an object Foo and instead of creating a new object Bar, we make a call to another Java object, which is a Factory object. The job of the Factory object is to create and hand over a new object Bar to the object Foo, as shown in the following figure. The whole purpose of this factory is to produce objects.

The Factory object reads from the configuration, which has metadata with details about the object that needs to be created. Configuration is a blueprint of all those objects that Factory creates. The Factory object reads from this configuration file, as shown here:

The Foo object interacts with the Factory object to get an object with a certain specification. Then the Factory object finds out what the blueprint for that particular object specification is and then creates a new object, as shown in the following figure:

Once the object has been created, Factory hands back the requesting Bar object to the Foo object. So, now Foo will have a new object it wants not using new() but using Factory, as shown in the following figure. This is something that Spring does.

Spring has objects of the BeanFactory type that behave like the Factory object. You specify the blueprints object in a configuration file, which is an XML file, and then supply it to BeanFactory. Later, if you need the instance of any object, you can ask BeanFactory for it, which then refers to the XML file and constructs the bean as specified. This bean is now a Spring bean as it has been created by Spring Container and is returned to you. Let's now summarize this:

The advantage here is that this new bean has been created in this BeanFactory, which is known by Spring. Spring handles the creation and the entire life cycle of this bean. So, in this case, Spring acts as container for this newly created Spring bean.

BeanFactory is defined by the org.springframework.beans.factory.BeanFactory interface. The BeanFactory interface is the central IoC container interface in Spring and provides the basic end point for Spring Core Container towards the application to access the core container service.

It is responsible for containing and managing the beans. It is a factory class that contains a collection of beans. It holds multiple bean definitions within itself and then instantiates that bean as per the client's demands.

BeanFactory creates associations between collaborating objects as they're instantiated. This removes the burden of configuration from the bean itself along with the bean's client. It also takes part in the life cycle of a bean and makes calls to custom initialization and destruction methods.

There are many implementations of the BeanFactory interface, with the org.springframework.beans.factory.xml.XmlBeanFactory class being the most popularly used one, which reads the bean definition and initiates them based on the definitions contained in the XML file. Depending on the bean definition, the factory will return either an independent instance or a single shared instance of a contained object.

This class has been deprecated in favor of DefaultListableBeanFactory and XmlBeanDefinitionReader, and the purpose of this implementation is just to explain BeanFactory. The constructor for XmlBeanFactory takes an implementation of the Resource interface as an argument, as shown in the following line of code:

XmlBeanFactory (Resource resource)

The Resource interface has many implementations. The two commonly used implementations are shown in the following table:

Let's assume that beans are configured in the beans.xml file located in the C drive:

...
<bean id="mybean" class="...">
  ...
</bean>
...

The code snippet to load the configuration file using BeanFactory is given as follows:

BeanFactory bfObj = new XmlBeanFactory (new FileSystemResource ("c:/beans.xml"));

MyBean beanObj= (MyBean) bfObj.getBean ("mybean");

Here, we've used FileSystemResource, which is one of the Resource interface implementations. The bfObj object corresponds to Spring Container, one that has loaded the bean definitions from the beans.xml file. BeanFactory is a lazy container, so at this point, only bean definitions get loaded, but beans themselves are not instantiated yet. At the second line, we call the getBean() method of the BeanFactory object created by passing the bean ID "mybean" as an argument to this method.

BeanFactory reads the bean definition of a bean with the ID "mybean" from Spring's beans.xml file, instantiates it, and then returns a reference.

The BeanFactory interface has different methods, such as getBean, containBean, and so on, for client code to call. You can get the complete list of these methods from http://docs.spring.io/spring/docs/2.0.x/reference/beans.html.

The BeanFactory container is usually used in very simple applications; however, in real-time projects, the ApplicationContext container is used.

The most commonly used ApplicationContext implementations are as follows:

To demonstrate an implementation of ApplicationContext, an example of PayrollSystem can be considered. It will have the EmployeeService interface, EmployeeServiceImpl class, and PayrollSystem class with the main method.

In the EmployeeService.java interface, you'll find the following code:

package org.packt.Spring.chapter2.ApplicationContext;

public interface EmployeeService {

   public Long generateEmployeeId();

}

The EmployeeService.java interface is a plain old Java interface that has a method named generateEmployeeId() to generate a unique employee ID on each call.

In the EmployeeServiceImpl.java class, you'll find the following code:

package org.packt.Spring.chapter2.ApplicationContext;

public class EmployeeServiceImpl implements EmployeeService {

   @Override
   public Long generateEmployeeId() {
          return System.currentTimeMillis();
   }
}

The EmployeeServiceImpl.java class implements the EmployeeService interface. This generateEmployeeId() class-implemented method is used to generate a unique employee ID on each part of this method based on the system's current time.

In the PayrollSystem.java class, you'll find the following code:

package org.packt.Spring.chapter2.ApplicationContext;

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class PayrollSystem {

   public static void main(String[] args) {

         ApplicationContext context = new ClassPathXmlApplicationContext(
                      "beans.xml");

         EmployeeService empService = (EmployeeServiceImpl) context
                     .getBean("empServiceBean");
         System.out.println("Unique Employee Id: " + empService.generateEmployeeId());
   }

}

The PayrollSystem.java class is a main class that contains the main() method. This method creates an instance of ApplicationContext, calls the getBean() method to get the bean of EmployeeService, and then prints the generated unique employee ID by calling the method from this bean.

The beans.xml file contains the bean definition for EmployeeServiceImpl, as shown in the following code snippet:

...
<bean id="empServiceBean" class="org.packt.Spring.chapter2.ApplicationContext.EmployeeServiceImp">
</bean>
...

When you successfully run PayrollSystem.java, the output will be printed on the console as follows:

Unique Employee Id: 1401215855074

The generated Employee Id value will be different for you when you run the preceding code in your local system as it is based on the current time.

A Spring application requires several beans or objects to work together in order to develop a loosely coupled application. Objects depend on each other to carry out their respective functions and this applies to beans too. Now let's understand DI.