the problems of the old-school EJB programming model that caused many enterprise Java projects to fail completely – or at least fail to satisfy their promises to some degree. The main problems of the old EJB programming model was that developers had to write several interfaces to create a business component, tight coupling between EJB and J2EE technologies was necessary, you couldn't run components outside the J2EE platform, there was difficulty in unit testing outside the container, long and complex develop-package-deploy-test cycles were required, and the characteristics and limitations of J2EE technologies required promotion of the procedural style of programming. Then you found out how those problems led to the creation of the POJO programming model, how the POJO programming model solves the problems of the EJB programming model, and how the POJO programming model helped J2EE to evolve into the new Java EE environment.
This chapter discussed why so many people insisted on using J2EE technologies and tried to deploy their enterprise applications despite all those obstacles in the J2EE environment. After identifying the attractive points of the J2EE platform, we defined what a container is, listed fundamental features a container should offer to its applications, and identified what makes a container lightweight by looking at its characteristics.
The last part of the chapter focused on what IoC is, and what any container should offer as its core services. We discussed how IoC helps make applications more modular and pluggable. The chapter wrapped up with an explanation of dependency injection, which is a form of IoC, and its two different types: setter injection and constructor injection.
EXERCISES
You can find possible solutions to the following exercises in Appendix A.
1. Investigate the in-container test frameworks available today. What are their biggest advantages and disadvantages compared to testing outside the container?
2. What IoC method is used by the new EJB programming model today?
3. Which dependency injection method can handle “circular dependencies” and which cannot?
▶ WHAT YOU LEARNED IN THIS CHAPTER
2
Dependency Injection with Spring
• Configuring and using Spring Container
• Using different types of configuration metadata to configure Spring Container
• Understanding dependency resolution
• Learning the advantages and disadvantages of autowiring
• Performing explicit bean lookups in Spring Container
• Learning different bean instantiation methods
• Understanding scoped beans and available scopes
• Learning how lazy bean creation works
• Understanding life-cycle callbacks
• Using bean definition profiles to create conditional bean configurations
CODE DOWNLOAD The wrox.com code downloads for this chapter are found at www.wrox.com/go/beginningspring on the Download Code tab. The code is in the Chapter 2 download and individually named according to the names throughout the chapter.
This chapter explains how you can apply dependency injection using the Spring Application Framework. You first look at different formats of configuration metadata necessary for the Spring Container to create and wire up objects in the system. The chapter includes examples for XML-, annotation-based, and Java-based configuration metadata formats. The chapter covers the two dependency injection methods in detail – setter injection and constructor injection – and explains how the dependency resolution process works in the container. You find out how you can override bean definitions, learn what autowiring means, and discover different modes of autowiring 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.
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
