The Spring Framework

In the introduction, we mentioned that the Spring Framework evolved from code written for the book Expert One-on-One J2EE Design and Development by Rod Johnson. This book was written to explain some of the complexities in JEE and how to overcome them. And while many of the complexities and problems in JEE have been solved in the newer JEE specifications (especially since JEE 6), Spring has become very popular due to its simple (not simplistic!) approach to building applications. It also offers a consistent programming model for different technologies, be they for data access or messaging infrastructure. The framework allows developers to target discrete problems and build solutions specifically for them.

The framework consists of several modules (see Figure 2-1) that work together and build on each other. We can pretty much cherry-pick the modules we want to use.

Most of the modules have a dependency on some other module in the Spring Framework. The core module is an exception to this rule. Figure 2-2 gives an overview of the commonly used modules and their dependencies on other modules. Notice that the instrumentation, aspect, and test modules are missing from the figure; this is because their dependencies depend on the project and what other modules are used. The other dependencies differ based on the needs of the project.

Dependency Injection

In dependency injection (DI), objects are given their dependencies at construction time. It is a Spring Framework foundation. You have probably heard of Inversion of Control (IoC).⁷ IoC is a broader, more general concept that can be addressed in different ways. IoC lets developers decouple and focus on what is important for a given part of an enterprise application, but without thinking about what other parts of the system do. Programming to interfaces is one way to think about decoupling.

The immediately preceding code isn’t particularly clean; for example, imagine multiple dependencies from different contexts. The code would quickly become messy and increasingly hard, if not impossible, to unit test.

As the name implies, constructor-based dependency injection uses the constructor to inject the dependencies in the object. Listing 2-3 uses constructor-based dependency injection. It has a constructor that takes two objects as arguments: com.apress.prospringmvc.moneytransfer.repository.AccountRepository and com.apress.prospringmvc.moneytransfer.repository.TransactionRepository. When we construct an instance of com.apress.prospringmvc.moneytransfer.constructor.MoneyTransferServiceImpl, we need to hand it the needed dependencies.

@Autowired and @Inject can be placed on methods and constructors to express dependency injection configuration, even when there are multiple arguments! When there is only a single constructor for the object, you can omit the annotations.

The first two reasons make our code easier to maintain. The fact that the code is easier to test should allow us to write unit tests to verify the behavior of our objects—and thus, our application.

ApplicationContexts

To do dependency injection in Spring, you need an application context. In Spring, this is an instance of the org.springframework.context.ApplicationContext interface. The application context is responsible for managing the beans defined in it. It also enables more elaborate things like applying AOP to the beans defined in it.

Spring provides several different ApplicationContext implementations (see Figure 2-3). Each of these implementations provides the same features but differs in how it loads the application context configuration. Figure 2-3 also shows us the org.springframework.web.context.WebApplicationContext interface, which is a specialized version of the ApplicationContext interface used in web environments.

Let’s look at a Java-based configuration file—the com.apress.prospringmvc.moneytransfer.annotation.ApplicationContextConfiguration class (see Listing 2-6). There are two annotations used in the class: org.springframework.context.annotation.Configuration and org.springframework.context.annotation.Bean. The first stereotypes our class as a configuration file, while the second indicates that the method’s result is used as a factory to create a bean. The name of the bean is the method name by default.

Configuration classes can be abstract; however, they cannot be final. To parse the class, Spring might create a dynamic subclass of the configuration class.

Finally, note that application contexts can be in a hierarchy. We can have an application context that serves as a parent for another context (see Figure 2-4). An application context can only have a single parent, but it can have multiple children. Child contexts can access beans defined in the parent context; however, parent beans cannot access beans in the child contexts. For example, if we enable transactions in the parent context, this won’t apply to child contexts (see the “Enabling Features” section later in this chapter).

This feature allows us to separate our application beans (e.g., services, repositories, and infrastructure) from our web beans (e.g., request handlers and views). It can be useful to have this separation. For example, assume that multiple servlets need to reuse the same application beans. Instead of recreating them for each servlet, we can simply reuse the already existing instances. This can be when there is one servlet handling the web UI and another that is handling the web services.

Aspect-Oriented Programming

To enable the features listed in Table 2-4, Spring uses aspect-oriented programming (AOP). AOP is another way of thinking about the structure of software. It enables you to modularize things like transaction management or performance logging, features that span multiple types and objects (cross-cutting concerns). In AOP, there are a few important concepts to keep in mind (see Table 2-7).

Table 2-7

Core AOP Concepts

Concept	Description
Aspect	The modularization of a cross-cutting concern. In general, this is a Java class with the org.aspectj.lang.annotation.Aspect annotation.
Join Point	A point during the execution of a program. This can be the execution of a method, the assignment of a field, or the handling of an exception. In Spring, a join point is always the execution of a method!
Advice	The specific action taken by an aspect at a particular join point. There are several types of advice: before, after, after throwing, after returning, and around. In Spring, an advice is called an interceptor because we are intercepting method invocations.
Pointcut	A predicate that matches join points. The advice is associated with a pointcut expression and runs at any join point matching the pointcut. Spring uses the AspectJ expression language by default. Join points can be written using the org.aspectj.lang.annotation.Pointcut annotation.

Now let’s look at transaction management and how Spring uses AOP to apply transactions around methods. The transaction advice, or interceptor, is org.springframework.transaction.interceptor.TransactionInterceptor. This advice is placed around methods with the org.springframework.transaction.annotation.Transactional annotation. To do this, Spring creates a wrapper around the actual object, which is known as a proxy (see Figure 2-5). A proxy acts like an enclosing object, but it allows (dynamic) behavior to be added (in this case, the transactionality of the method).

The org.springframework.transaction.annotation.EnableTransactionManagement annotation registers the beans containing the pointcut (acting on the org.springframework.transaction.annotation.Transactional annotation). At this point, the interceptor is ready to use. The other annotations for enabling features work similarly; they register beans to enable the desired feature, including AOP (and thus proxy creation) for most features.

Web Applications

So how does all that technology apply to a web application ? For example, how do application contexts play a role? And what about all the other things mentioned?

When developing a web application, there is actual business logic (e.g., services, repositories, and infrastructure information), and there are web-based beans. These things should be separated, so we need to have multiple application contexts and relationships.

We also need code that bootstraps our application, or else nothing happens. In this chapter’s examples, we used a MoneyTransferSpring class with a main method to start the application context. This is not something we can do in a web environment. Spring ships with two components that can bootstrap an application: org.springframework.web.servlet.DispatcherServlet and org.springframework.web.context.ContextLoaderListener. Both components bootstrap and configure an application context.

Spring Boot

All the things mentioned previously in this chapter also apply to Spring Boot. Spring Boot builds upon and extends the features of the Spring Framework. It does make things a lot easier, however. Spring Boot automatically configures the features it finds on the classpath by default. When Spring Boot detects Spring MVC classes, it starts Spring MVC. When it finds a DataSource implementation, it bootstraps it.

Customizations can be done by adding properties to the application.properties or application.yml files. You can configure the datasource, view handling, and server port, among others, through this. Another option is to configure things manually, as you would do in a regular Spring application. When Spring Boot detects the preconfigured parts of a feature, it typically refrains from autoconfiguring that feature.

The BookstoreApplication class has @SpringBootApplication, which enables autoconfiguration of detected features and third-party libraries. In this case, it extends SpringBootServletInitializer because the application is packaged as a WAR and deployed onto a container. Instead of writing our own WebApplicationInitializer, Spring Boot provides one out-of-the-box. It enables most Spring Boot features in a classic container.

One of the nice features of Spring Boot is that when running on different environments, we can use profiles to load different/additional configuration files. For instance, when enabling the local profile, Spring Boot would also load an application-local.properties or application-local.yml. When running in a cloud-based situation, the properties could also be obtained from a Git repository or the Docker environment.

Summary

This chapter covered the bare basics of Spring Core. We reviewed dependency injection and briefly covered three different versions of dependency injection. We also covered constructor-based, setter-based, and annotation-based dependency injection.

Next, we stepped into the Spring world and examined org.springframework.context.ApplicationContexts, including the role they play in our application. We also explained the different application contexts (e.g., XML or Java-based) and the resource loading in each of them. In our web environment, we use a specialized version of an application context in an implementation of the org.springframework.web.context.WebApplicationContext interface. We also covered how beans in an application context are singleton scoped by default. Fortunately, Spring provides us with additional scopes, such as request, session, globalSession, prototype, application, and thread.

To use different configurations in different environments, Spring also includes profiles. We briefly explained both how to enable profiles and how to use them. We use profiles in our sample application when we test it and deploy it to Cloud Foundry.

We also delved into the way several enabling annotations are required for Spring to enable certain features. These annotations register additional beans in the application context that enable the desired feature. Most of these features rely on AOP to be enabled (e.g., declarative transaction management). Spring creates proxies to apply AOP to beans registered in our application contexts.

Finally, we took a quick look at Spring Boot and how that makes our lives as software developers easy. Spring Boot uses autoconfiguration to configure features detected on the classpath. It builds upon and extends the Spring Framework where needed.

The next chapter looks at the architecture of an MVC web application, the different layers, and their roles in our application.