In my tutorials about the Spring framework, I often use the object of the ApplicationContext interface as a Spring container to call the object that I need to retrieve. For example, in the previous tutorial:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
package com.huongdanjava.springbeanautowiring; import org.springframework.context.ApplicationContext; import org.springframework.context.support.ClassPathXmlApplicationContext; public class Application { public static void main(String[] args) { ApplicationContext context = new ClassPathXmlApplicationContext("spring.xml"); Room room = (Room) context.getBean("room"); if (room.getTable() != null) { System.out.println(room.getTable().toString()); } } } |
But in fact, Spring also provides us with another interface that the implementation object actually is the Spring container, called BeanFactory.
So now, if you replace the ApplicationContext:
|
1 |
ApplicationContext context = new ClassPathXmlApplicationContext("spring.xml"); |
by BeanFactory as the following code:
|
1 2 3 |
DefaultListableBeanFactory beanFactory = new DefaultListableBeanFactory(); XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(beanFactory); reader.loadBeanDefinitions(new ClassPathResource("spring.xml")); |
Then the results are as normal when you run.
So what’s the difference between these two interfaces? Why did I only use the ApplicationContext without beating the BeanFactory? In this tutorial, I will clarify for you guys!
The first thing I would like to say is that the ApplicationContext interface extends from the BeanFactory interface, but BeanFactory only provides the basic functionality for Dependency Injection in Spring, while the ApplicationContext has other more advanced features.
The first difference in these two interfaces is that they both provide the ability to retrieve the object we need in Spring’s container using the getBean() method, but the BeanFactory only produces the object we need when we call its getBean() method and ApplicationContext will create all the objects we need as soon as we call to Spring container.
To prove this, I will continue the example that I did in the previous tutorial.
OK, now I need to know when calling to Spring container, what does it do? At DEBUG level, Spring will tell us all about that.
So I will add the reload4j library to my existing project and configure our program to run at DEBUG level. As follows:
The contents of the log4j.properties file:
|
1 2 3 4 5 6 |
log4j.rootCategory=DEBUG, STDOUT log4j.appender.STDOUT=org.apache.log4j.ConsoleAppender log4j.appender.STDOUT.layout=org.apache.log4j.PatternLayout log4j.appender.STDOUT.Threshold=ERROR, DEBUG log4j.appender.STDOUT.layout.ConversionPattern=[%d{HH:mm:ss}] %c : %m%n |
Add dependency of log4j library to pom.xml file:
|
1 2 3 4 5 |
<dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-reload4j</artifactId> <version>2.0.6</version> </dependency> |
Now in the main method of the Application class, we will remove all the code except for the code that calls to the Spring container, which means that the Application class just has content as follows:
|
1 2 3 4 5 6 7 8 9 10 11 |
package com.huongdanjava.springbeanautowiring; import org.springframework.context.ApplicationContext; import org.springframework.context.support.ClassPathXmlApplicationContext; public class Application { public static void main(String[] args) { ApplicationContext context = new ClassPathXmlApplicationContext("spring.xml"); } } |
Now when I run the application, you’ll see the following logs:
|
1 2 3 4 5 |
[13:44:39] org.springframework.context.support.ClassPathXmlApplicationContext : Refreshing org.springframework.context.support.ClassPathXmlApplicationContext@2ac1fdc4 [13:44:39] org.springframework.beans.factory.xml.XmlBeanDefinitionReader : Loaded 3 bean definitions from class path resource [spring.xml] [13:44:39] org.springframework.beans.factory.support.DefaultListableBeanFactory : Creating shared instance of singleton bean 'org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor#0' [13:44:39] org.springframework.beans.factory.support.DefaultListableBeanFactory : Creating shared instance of singleton bean 'table' [13:44:39] org.springframework.beans.factory.support.DefaultListableBeanFactory : Creating shared instance of singleton bean 'room' |
If you take a close look at these logs, you will see that when you call the Spring container using the ApplicationContext, all objects declared in the Spring configuration file are instantiated.
Now, we will use BeanFactory instead of ApplicationContext. The contents of the application file will be as follows:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
package com.huongdanjava.springbeanautowiring; import org.springframework.beans.factory.support.BeanDefinitionRegistry; import org.springframework.beans.factory.support.DefaultListableBeanFactory; import org.springframework.beans.factory.xml.XmlBeanDefinitionReader; import org.springframework.core.io.ClassPathResource; public class Application { public static void main(String[] args) { BeanDefinitionRegistry beanFactory = new DefaultListableBeanFactory(); XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(beanFactory); reader.loadBeanDefinitions(new ClassPathResource("spring.xml")); } } |
Then run, and observe the logs:
|
1 |
[14:28:32] org.springframework.beans.factory.xml.XmlBeanDefinitionReader : Loaded 3 bean definitions from class path resource [spring.xml] |
you will see that no object is created at all.
If you now add the getBean() code, our object will be created in the Spring container:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
package com.huongdanjava.springbeanautowiring; import org.springframework.beans.factory.support.DefaultListableBeanFactory; import org.springframework.beans.factory.xml.XmlBeanDefinitionReader; import org.springframework.core.io.ClassPathResource; public class Application { public static void main(String[] args) { DefaultListableBeanFactory beanFactory = new DefaultListableBeanFactory(); XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(beanFactory); reader.loadBeanDefinitions(new ClassPathResource("spring.xml")); Table table = (Table) beanFactory.getBean("table"); } } |
Log content:
|
1 2 |
[14:31:45] org.springframework.beans.factory.xml.XmlBeanDefinitionReader : Loaded 3 bean definitions from class path resource [spring.xml] [14:31:45] org.springframework.beans.factory.support.DefaultListableBeanFactory : Creating shared instance of singleton bean 'table' |
The second difference between these two interfaces is in their implementation. For BeanFactory we often use the object that implements it as DefaultListableBeanFactory and the ApplicationContext is ClassPathXmlApplicationContext.
The third difference between these two interfaces is the ability to support multiple languages. For example, you have a sentence translated into three different languages: Vietnamese, English, and French. ApplicationContext gives us the ability to derive the contents of this statement in three different languages using the getMessage(String code, Object [] args, Locale local) method, while BeanFactory does not support us doing this.
In addition, there are a number of different points between these two interfaces, but since this tutorial is long, these different points must have specific examples for you to understand, then I should not be listed here.
In this tutorial, my goal is to tell you that: in addition, besides calling the Spring container using the ApplicationContext, we can also use the BeanFactory. ApplicationContext supports more powerful functions so most of us will use this interface.
