This is a series and it would make a lot of sense if read in a sequence. You can find all the posts under the heading “Spring Beginners to Professionals“. In the previous post we discussed the BeanFactory in detail. Here we will try and put some more effort in understanding the ApplicationContext and its flavors.
Understanding the ApplicationContext
We have reached far enough and have acquired good knowledge to understand the concept of the Application Context. It is a sub interface of ListableBeanFactory and HierarchicalBeanFactory discussed in the previous post.
Why do we need an ApplicationContext ?
What does this mean and why do we need a specialized version of BeanFactory if we are getting all the dependency injection using the BeanFactory we already have?
Although we agree that an application is mostly about beans collaborating with each other to accomplish a bigger task. But these collaborations are of different types and it would be complicated to handle all of them by custom coding using only the BeanFactory APIs.
- All applications need to deal with properties files and inject properties and other environment information into beans
- Most applications need to deal with message bundle and I18n features
- Applications also require static and dynamic resources (like images, URLs etc.)
- Most of the applications need to publish various kinds of application events to other collaborating beans and external objects.
- And of course applications need collaborating beans.
The BeanFactory is only capable of addressing the last point, whereas the Application Context provides first hand support for all the above points.
What makes a BeanFactory an ApplicationContext ?
The ApplicationContext inherits from many interfaces like MessageSource, ApplicationEventPublisher, ResourcePatternResolver, EnvironmentCapable and the two bean factories we discussed above.
All these interfaces define above mentioned specific features and hence, the application context is capable of offering them all by itself. Any class which implements the ApplicationContext interface must implement all these APIs.
Spring provides the implementation as an abstract class, the AbstractApplicationContext which in turn is implemented by usable concrete classes like ClassPathXMLApplicationContext, FileSystemXMLApplicationContext, AnnotationConfigApplicationContext and many more. We have already seen these classes in simple code blocks in the previous posts.
So, here I introduce you to the most important class in the Spring Framework and that is AbstractApplicationContext. This class is the core of Spring and all the action happens here.
In case your application is not able to inject and supply all the components and you feel that something is messed up, a good place to start debugging is the refresh method of this class.
This class is responsible for instantiating, configuring and assembling the beans. The ClassPathXMLApplicationContext and FileSystemXMLApplicationContext performs this job by reading an XML file stored in classpath or file system respectively. However, the AnnotationConfigApplicationContext uses a set of one or more Java classes annotated by @Configuration annotation.
There is a lot to the AbstractApplicationContext, mostly around the application bootstrapping. This we will cover in detail in a separate post. Also, I mentioned many features of the ApplicationContext, which we will discuss one by one in the coming posts. The first one would be resource loading in Spring.
All these topics are good candidates for a Spring interview for a senior level. So. I would request you to pay some more attention and ask questions in the comments below. That would help me elaborate more on the topics if required.
Stay Connected and Happy Learning.