Spring Book – Chapter 3 – Spring Quick Start

The Initialization Phase

This is the phase in which instantiation of Spring’s IoC container takes place. It prepares all the beans to be used in an enterprise application. All the application services in an application get created, configured, and if any system resources are required, accordingly allocated and kept ready. The application is not usable if this phase is not complete. Even though we covered the crux of what happens in this phase, the actual nitty-gritty involved in this phase is more demanding and complex. Figure 3-6 shows the various subphases/steps.

Figure 3-6. BeaniInitialization steps

Load Bean Definitions

As shown in Figure 3-6, the following steps occur:

1. The configuration XML files parsed

2. Bean definitions are loaded onto the Spring context, with each bean having a unique ID

3. Special BeanFactoryPostProcessor beans are invoked, which can modify the definition of a bean in the Spring context

BeanFactoryPostProcessor

Custom modification of an application context’s bean definitions is possible with the interface org.springframework.beans.factory.config.BeanFactoryPostProcessor. Application contexts can autodetect BeanFactoryPostProcessor beans in their bean definitions and apply them before any other beans getting created. These are very useful for system administrators for overriding bean properties in custom configuration files. Using this it allows modification of the application context’s internal bean factory after its standard initialization. All bean definitions will be loaded, but no beans will have be instantiated. It allows for overriding or adding properties even to eager-initializing beans. Listing 3-8 shows the interface BeanFactoryPostProcessor interface.

Listing 3-8. Source for BeanFactoryPostProcessor interface

Useful implementations provided by the Spring Framework are:

  • org.springframework.beans.factory.config.CustomEditorConfigurer—Allows for convenient registration of custom property editors. The property editor provides support for GUIs that want to allow users to edit a property value of a given type.
  • org.springframework.beans.factory.config.CustomScopeConfigurer—Allows for declarative registration of custom scopes.
  • org.springframework.beans.factory.config.PreferencesPlaceholderConfigurerTries to resolve placeholders as keys first in the user preferences, then in the system preferences, then in this configurer’s properties. Thus, it behaves like PropertyPlaceholderConfigurer if no corresponding preferences are defined.
  • org.springframework.beans.factory.config.PropertyOverrideConfigurer—A property resource configurer that overrides bean property values in an application context definition. It pushes values from a properties file into bean definitions. In contrast to PropertyPlaceholderConfigurer, the original definition can have default values or no values at all for such bean properties. If an overriding properties file does not have an entry for a certain bean property, the default context definition is used. In case of multiple PropertyOverrideConfigurers that define different values for the same bean property, the last one will win (due to the overriding mechanism).
  • org.springframework.beans.factory.config.PropertyPlaceholderConfigurer—A property resource configurer that resolves placeholders in bean property values of context definitions. It pulls values from a properties file into bean definitions. In contrast to PropertyOverrideConfigurer, this configurer allows you to fill in explicit placeholders in context definitions. Therefore, the original definition cannot specify any default values for such bean properties, and the placeholder properties file is supposed to contain an entry for each defined placeholder.
  • org.springframework.beans.factory.config.PropertyResourceConfigurer—Allows for configuration of individual bean property values from a property resource—that is, a properties file. Useful for custom config files targeted at system administrators that override bean properties configured in the application context. Two concrete implementations are provided in the distribution:
  • org.springframework.beans.factory.config.PropertyOverrideConfigurer for beanName.property=value style overriding (pushing values from a properties file into bean definitions).
  • org.springframework.beans.factory.config.PropertyPlaceholderConfigurer for replacing ${…} placeholders (pulling values from a properties file into bean definitions)

You can write your own custom BeanFactoryPostProcessor by implementing the BeanFactoryPostProcessor interface. You will have to implement the only method, postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory).

Initialize Bean Instances

In this phase, each bean is created in the right order with all its dependencies injected automatically. After this, it goes through a post-processing phase in which more configurations and initialization can occur. After this, the bean is fully initialized and ready to use in your application. Types of bean processing that can occur using the bean post processor are:

  • Initializers
  • All other activities

These are explained in detail in the following sections.

Initializers

Initializers are bean post processors, which initialize the beans if instructed to do so by Spring Framework. A bean can optionally register for one or more initialization callbacks. This can be used to execute custom initialization behaviors by an initializing bean post processor. A common way to register the bean for initialization callback is to use @PostConstruct, a standard Java Annotation (JSR-250). Since it’s standard Java Annotation as opposed to Spring annotation, it avoids dependency on Spring APIs. If you so instruct it, Spring doesn’t look into these annotations and do the necessary action. This is done in the configuration file (if configuration is done through XML, as shown in Listing 3-9). Declare the bean post processor to be an anonymous bean (a bean declaration that doesn’t have a unique ID) in the configuration file. In older versions of Spring, declaring Spring to use these annotations was cumbersome, but now it is much simpler. Both declaration methods are shown in the following listings.

Listing 3-9. Old way of doing XML configuration

Listing 3-10. New way of doing XML configuration

Registering initialization callback using javax.annotation.PostConstruct annotation is done as follows:

Listing 3-11. Usage of @PostConstruct annotation

org.springframework.beans.factory.InitializingBean is a marker interface, which is a useful tool for Spring to use to perform certain actions upon bean initialization. For beans implementing InitializingBean, it will run afterPropertiesSet() after all bean properties have been set.

Listing 3-12. Usage of InitializingBean interface

If you would like to initialize the bean using the init-method, do the following in XML configuration and Java code shown in Listing 3-13 and 3-14, respectively:

Listing 3-13. Usage of init-method in the XML configuration

Listing 3-14. Corresponding method declaration in Java Code to do the bean initialization

All Other Activities

You can use these bean post processors for any other activities you would like to do in your beans. It can run before or after the bean initialization step. Using one of the very important extension points in Spring, called org.springframework.beans.factory.config.BeanPostProcessor, you can modify the bean instances any way you like in your application. Even though Spring provides several useful implementations for this, you can implement the BeanPostProcessor interface to do your bean post processing in your custom way. ApplicationContext can autodetect BeanPostProcessor beans in their bean definitions and apply them to any beans subsequently created. Plain bean factories allow for programmatic registration of post processors, applying to all beans created through this factory.

Listing 3-15. The BeanPostProcessor Interface

Following is a little more information about the postProcess methods:

  • postProcessBeforeInitialization—Apply this BeanPostProcessor to the given new bean instance before any bean initialization callbacks (such as InitializingBean’s afterPropertiesSet() or a custom init-method). The bean will already be populated with property values. The returned bean instance may be a wrapper around the original.
  • postProcessAfterInitialization—Apply this BeanPostProcessor to the given new bean instance after any bean initialization callbacks (such as InitializingBean’s afterPropertiesSet() or a custom init-method). The bean will already be populated with property values. The returned bean instance may be a wrapper around the original.

Some common examples of implementation of BeanPostProcessor by Spring Framework are:

  • org.springframework.beans.factory.annotation.RequiredAnnotationBeanPostProcessor—BeanPostProcessor implementation that enforces required JavaBean properties to have been configured. Required bean properties are detected through a Java 5 annotation, which is, by default, Spring’s required annotation. A default RequiredAnnotationBeanPostProcessor will be registered by the context: annotation-config and context: component-scan XML tags. Remove or turn off the default annotation configuration there if you intend to specify a custom RequiredAnnotationBeanPostProcessor bean definition.
  • org.springframework.context.annotation.CommonAnnotationBeanPostProcessor—BeanPostProcessor implementation that supports common Java annotations out of the box, in particular the JSR-250 annotations in the javax.annotation package. These common Java annotations are supported in many Java EE 5 technologies (e.g. JSF 1.2), as well as in Java 6’s JAX-WS. This postprocessor includes support for the PostConstruct and PreDestroy annotations — as init annotation and destroy annotation, respectively.

Examination Tip: You will have to clearly understand the difference between BeanFactoryPostProcessor and BeanPostProcessor. BeanPostProcessor gives you a chance to process an instance of a bean created by the IoC container after its instantiation and then again after the initialization lifecycle event has occurred on the instance. BeanFactoryPostProcessor lets you modify the actual bean definition instead of the instance as it’s created.

Page Visitors: 2090

The following two tabs change content below.
Tomcy John

Tomcy John

Blogger & Author at javacodebook
He is an Enterprise Java Specialist holding a degree in Engineering (B-Tech) with over 10 years of experience in several industries. He's currently working as Principal Architect at Emirates Group IT since 2005. Prior to this he has worked with Oracle Corporation and Ernst & Young. His main specialization is on various web technologies and acts as chief mentor and Architect to facilitate incorporating Spring as Corporate Standard in the organization.
Tomcy John

Latest posts by Tomcy John (see all)

Leave a Reply

Your email address will not be published. Required fields are marked *