Application Context
The org.springframework.beans and org.springframework.context packages are the basis for Spring Framework’s IoC container. The org.springframework.beans.factory.BeanFactory interface provides an advanced configuration mechanism capable of managing any type of object in an application; org.springframework.context.ApplicationContext is a subinterface of BeanFactory. BeanFactory provides the configuration framework and basic functionality, and ApplicationContext adds more enterprise-specific functionality and is the complete superset of BeanFactory.
ApplicationContext represents the Spring IoC container and is responsible for instantiating, configuring, and assembling the objects that form the backbone of your enterprise application. Several implementations of the ApplicationContext interface are supplied out-of-the-box with Spring; these include org.springframework.context.support.ClassPathXmlApplicationContext and org.springframework.context.support.FileSystemXmlApplicationContext, which we explain in detail later in this chapter.
All the beans inside the Spring container are initialized before they are used. These are cached so that access to these beans is fast. Beans are always created in order based on the dependencies. Each bean is bound to a unique ID, which can be used to get the bean reference explicitly in the application code.
According to Spring reference, every bean has one or more IDs (also called identifiers, or names; these terms refer to the same thing). These ID’s must be kept unique within the Spring container in which the bean is hosted. A bean should ideally have only one ID, but if a bean has more than one ID, the extras will be considered as aliases to the declared bean.
When using XML-based configuration metadata for configuring your Spring container, you use either the ID or name attributes to declare the bean. The ID attribute is a real XML element and due to this the XML parser will be bale to do some extra validation which can be done to any XML document. The ID attribute allows you to specify exactly one ID. It’s very common practice to specify or rather identify bean in the configuration file with ID attribute the XML specification does limit the characters that are legal in XML ID attribute. This can create unwanted constraint, but if you need to use one of these special XML characters, or want to introduce other aliases to the declared bean, you may also, or instead, specify one or more bean ID’s separated by a comma (,), semicolon (;), or white space in the name attribute.
ApplicationContext (see Figure 3-4) encapsulates the actual bean implementation based on the deployment, whether it is a Web application or a stand-alone Java application. There are various ways to change this. One is to have different configuration files based on the deployment required, which the deployment team can decide. Nowadays, because XML is also considered to be code, this solution of having multiple configuration files based on the deployment scheme can be cumbersome. Figure 3-4 shows only the main superinterfaces from which the interface ApplicationContext inherits. ApplicationContext provides:
- Bean factory methods for accessing application components. Inherited from org.springframework.beans.factory.ListableBeanFactory.
- The ability to load file resources in a generic fashion. Inherited from the org.springframework.core.io.ResourceLoader interface.
- The ability to publish events to registered listeners. Inherited from the org.springframework.context.ApplicationEventPublisher interface.
- The ability to resolve messages, supporting internationalization. Inherited from the org.springframework.context.MessageSource interface.
- Inheritance from a parent context. Definitions in a descendant context will always take priority. This means, for example, that a single parent context can be used by an entire Web application, while each servlet has its own child context that is independent of that of any other servlet.
Using the latest release of Spring Framework, we can have the concept of profiles, which can be implemented by Java, Annotations, and, again, in XML, in the same file differentiated by profile names.
Figure 3-4. Structure of org.springframework.context.ApplicationContext interface
Application Context Lifecycle
Application Context in Spring gets created from XML configuration, using Java Configuration or by using Java Spring Annotations. If using XML files for configurations, bean definitions can be loaded from following sources, and Spring provides appropriate Application Context implementation out-of-the-box:
- org.springframework.context.support.ClassPathXmlApplicationContext – Loads configuration file from classpath
- org.springframework.context.support.FileSystemXmlApplicationContext – Loads configuration file from local file system using absolute path or relative path.
- org.springframework.web.context.support.XmlWebApplicationContext – Loads the configuration file from /WEB-INF/applicationContext.xml for the root context, and /WEB-INF/test-servlet.xml for a context with the namespace test-servlet (like for a DispatcherServlet instance with the servlet-name test).
A context can be configured from multiple files. You can use the preceding default methods provided by Spring, or you can write a custom method for loading bean definitions. Since the beans can be loaded from multiple locations, we can logically group these files, which promotes modularity as well. It is a best practice to separate out application bean definitions (business-application-specific beans) from infrastructure beans (security-data-source bean definitions).
As shown in Figure 3-5, there are three main phases in the lifecycle of the Spring Application Context: initialization, use, and destruction. These are explained in detail in following sections.
Figure 3-5. ApplicationContext lifecycle
Page Visitors: 2585
Tomcy John
Latest posts by Tomcy John (see all)
- A Guide to Continuous Improvement for Architects - February 2, 2023
- Cloud-first Architecture Strategy - January 26, 2023
- Architecture Strategy and how to create One - January 24, 2023