Bean Lifecyle
The entire Bean objects defined in the Xml Configuration File undergoes a Standard Lifecycle Mechanism. Lifecycle interfaces like InitializingBean and DisposableBean are available. Care should be taken while using these Interfaces. Since these are Spring specific Interfaces, your application code will tightly be Coupled with the Spring Implementation. So define and use these interfaces when there is really a need.
The InitializingBean interface has a single method called afterPropertiesSet() which will called immediately after all the property values that have been defined in the Xml Configuration file is set. Any customized initiation logic or mandatory checking can be done here. Similarly, the DisposableBean has a single method called destroy() which will be called during the shut down of the Bean Container.
Following is the code snippet illustrating the usage of these interfaces,
Employee.java
package net.javabeat.articles.spring.complex;
import org.springframework.beans.factory.*;
public class Employee implements InitializingBean, DisposableBean{
private String name;
private String id;
public void afterPropertiesSet() throws Exception {
System.out.println(“Employee->afterPropertiesSet() method called”);
}
public void destroy() throws Exception {
System.out.println(“Employee->destroy() method called”);
}
}
Controlling the Order of Creation of Beans
Sometimes we may end up in a situation that Component A must be created before Component B. In such a case we can use the depends-on attribute which takes a list of previously defined Bean Definition identifiers. For example, consider that we have three Bean Classes namely Employee, Department and Organization. And the situation is that we want the Creation of Bean objects to be followed in this order, Organization followed by Department and then Employee.
Following is the Xml snippet code that achieves the same,
Creating Bean Instances through Factory classes
Suppose say that we already have a Factory class for creating a Bean object and we want to make use of this factory class. Then the usage of ‘factory-method’ and ‘factory-bean’ attributes will come into picture. Let us have the following sample code to make things clearer.
Team.java
public class Team{
private String name;
}
TeamFactory.java
public class TeamFactory {
public static Team getTeamUsingStaticMethod(){
System.out.println(“Static Method Called”);
return new Team();
}
public Team getTeamNormalMethod(){
System.out.println(“Instance Method Called”);
return new Team();
}
}
The above Factory class has two methods that will return Team objects. One is the static factory method and the other one is the regular instance method. If we want make use of the static method TeamFactory.getTeamUsingStaticMethod(), then we should change the bean definition in the Configuration File to something like the following,
India
In the above case, the class attribute must point to the name of the Factory class and the factory-method attribute must be the name of the static method which will return the instance. And as usual, the property element is used to pass values to the Team object while creating the instance.
If instead, we want to make use of the normal instance method, i.e. TeamFactory.getTeamNormalMethod(), then we should define the factory class itself as a bean and then have to make references to the instance method in the Bean definition. Consider the following changes in the Xml File,
Australia
The first thing to note is a Bean definition is made for the Factory class TeamFactory and then in the definition of the bean itself, the ‘factory-bean’ attribute points to the identifier that was previously defined with the factory-method attribute pointing to the name of the instance method that will create Team objects.
Bean Inheritance
Minimal support of Inheritance is given between the Bean Components in the form of the attribute ‘parent’ within the ‘bean’ tag. For example, consider the following classes Planet and Earth. The Class Planet has two properties namely ‘name’ and ’shape’. The values for these properties might be ‘Planet’ and ‘Elliptical’. The other class Earth (which is a Planet too) extends the Planet class, but we wish that for the Class Earth the property values should be ‘Earth’ and ‘Elliptical’.
So, we are doing two things here. One is, the class Earth is extending from the class Planet. And the other thing is the values for the Planet object (‘Planet, ‘Elliptical’) is overridden for the Earth object with values (‘Earth’ and ‘Elliptical’). Following is the code snippet for the classes Planet and Earth.
Planet.java
public class Planet {
private String name;
private String shape;
}
Earth.java
public class Earth extends Planet {
}
And the changes in the Xml Configuration File are the inclusion of the attribute ‘parent’ in the bean definition for the Earth object. Also note that since we want the value ‘Earth’ for the name property we have overridden the value just by redefining it.
planet-earth.xml
Planet
elliptical
Earth
Here is the code snippet of the Client Application,
Client Application
Resource resource = new FileSystemResource(“./src/resources/planet-earth.xml”);
BeanFactory factory = new XmlBeanFactory(resource);
Planet planet = (Planet)factory.getBean(“planet”);
System.out.println(planet);
Planet earth = (Planet)factory.getBean(“earth”);
System.out.println(earth);
Conclusion
Even though there are lots and lots of functionality in the Spring Core, this article attempted to cover only the basic things. More specifically it concentrated on the various Spring Modules that are resting on top of the Spring Core Framework. Then a good treatment along with some samples is given in the topic Inversion of Control and how well this principle fits into the Spring Architecture is discussed. Then the remaining part of the article explored much about the usage of the various Configuration Stuffs available in the Xml Configuration File. More specifically, Creation of Bean Objects, Mapping between Bean Objects, Collection Mapping, Instantiation through Factory Class, Bean Inheritance, Bean Lifecycle, Configuration Files Import, Controlling the Bean Creation Order is given good coverage.
