.

that are available in the container.

      The lifetimes of Spring-managed beans can be different according to their scope definitions. This chapter lists the scopes supported by the Spring Container and explains how different scopes behave in the system. You can create Spring beans either during startup (eager initialization), or delay their creation until they are needed in the system (lazy initialization). In this chapter you find out how those bean initialization methods work, the pros and cons of each, and the different bean instantiation methods provided by the Spring Container.

      The chapter wraps up with coverage of new features, such as bean definition profiles and environment abstraction introduced in Spring 3.1, which helps you conditionally handle bean definitions according to the runtime platform of the application or its environment.

      SPRING IOC CONTAINER

      The core of the Spring Application Framework is its Inversion of Control (IoC) Container. Its job is to instantiate, initialize, and wire up objects of the application, as well as provide lots of other features available in Spring throughout an object's lifetime. The objects that form the backbone of your application, and are managed by Spring Container, are called beans. They are ordinary Java objects – also known as POJOs – but they are instantiated, assembled by the Spring Container, and managed within it.

      Configuration Metadata

The Spring Container expects information from you to instantiate beans and to specify how to wire them together. This information is called configuration metadata. Together with this configuration metadata, the Spring Container takes classes written in the application and then creates and assembles beans in it. Figure 2.1 depicts this process.

FIGURE 2.1

      The traditional form of configuration metadata is XML; however, it is not the only form. Annotation-based and Java-based configuration metadata options are also available. The nice thing is that the Spring Container is independent of the configuration metadata format. You can use any format you like and even mix them together in the same application. The following code is an example of XML configuration metadata:

      In this code, all beans are defined within the <beans> element, and each bean is defined using the <bean> element. Beans have names defined with the id attribute. They are accessed using their names either from the application or from another bean definition in the configuration metadata. In the preceding example, the accountService bean has a property called accountDao, and this property is satisfied with the accountDao bean defined in the configuration.

      The next code snippet is an example of annotation-based configuration metadata:

      Here, beans are defined using Java annotations. The @Service and @Repository annotations are used to define two beans. They are actually a more specialized form of the @Component annotation. The @Autowired annotation is used to specify bean dependency that will be injected by the Spring Container at run time. Annotation-based configuration metadata was introduced with Spring 2.5.

      The following code snippet exemplifies Java-based configuration metadata:

      You define beans in a Java class annotated with @Configuration. Within that class each public method marked with the @Bean annotation corresponds to a bean definition. Beans are instantiated by invoking an appropriate constructor from their concrete classes, then their dependencies are obtained by calling other bean definition methods, and those obtained dependencies are injected into the bean. Java-based configuration metadata was introduced with Spring 3.0.

      In a big project, it's a good idea to divide configuration metadata into several different files so that it can be managed easily and can be managed by different developers at the same time. This division usually reflects the layers of the application. You create a separate bean definition file or class for each layer in the application, and you also create some additional bean definition files or classes for other container-specific configuration tasks as well. Therefore, for a typical web application project that's developed using Spring, it is very common to see bean definition files or classes similar to these:

      • Beans that operate in the web/presentation layer of the application are defined in the beans-web.xml file or ConfigurationForWeb class.

      • Beans that operate in the service/business layer of the application are defined in the beans-service.xml file or the ConfigurationForService class.

      • Beans that operate in the data access layer of the application are defined in the beans-dao.xml file or the ConfigurationForDao class.

      • Beans that are necessary for several container-specific features to be activated are defined in the beans-config.xml file or the ConigurationForConfig class.

      • Beans that are used for security requirements of the application are defined in the beans-security.xml file or the ConfigurationForSecurity class.

      Your application doesn't have to have this exact collection of files. The number and granularity of configuration metadata files varies according to the architecture and specific requirements of the target application. However, the files in this list are a good starting point, and you can always add new ones and divide existing ones according to your needs.

      Configuring and Using the Container

      The Spring Container is also a Java object, which is created in the application at some specific point and then allowed to manage the rest of the application. You can instantiate the Spring Container in basically two different ways. In standalone applications, you use the programmatic approach. In web applications, on the other hand, the declarative approach is preferable with the help of some configuration within the web.xml file.

The following Try It Out shows how the Spring Container can be created and used in a standalone environment using Java-based configuration. We try to employ a simple form of layered architecture by defining beans corresponding to each layer illustrated in the Figure 2.2:

FIGURE 2.2