Mockito for Spring

Spring is an open source enterprise application development framework for Java. It was first written by Rod Johnson and released under the Apache 2.0 license in June 2003.

Spring Framework provides comprehensive infrastructure support for developing Java applications. Spring handles the infrastructure for us and allows us to focus on our application logic. Spring enables us to build applications from Plain Old Java Objects (POJOs) and apply enterprise services non-invasively to POJOs.

The following are examples of POJO-based application development:

In a nutshell, Spring can be described as follows:

The following are advantages of Spring:

Spring projects provide infrastructure for building security configuration, web applications, big data, LDAP, and so on. Spring Framework is one of the Spring projects.

There are various Spring projects that can be used. In this book, we'll be using Spring 4.

The following are the icons of some Spring projects:

The following are all Spring projects as of September 2014:

Spring Framework is modular, and its features are organized into different modules. This section talks about core Spring modules. The following are the Spring 4 modules:

The test module

The test module supports the unit testing and integration testing of Spring components with JUnit or TestNG.

The following figure represents the Spring 4 modules:

Inversion of Control (IoC) and dependency injection (DI) are used interchangeably. IoC is achieved through DI. DI is the process of providing dependencies and IoC is the end result of DI. Spring's IoC container enforces the DI pattern for your components, and this leaves them loosely coupled and allows you to code to abstractions.

Dependency injection is a style of object configuration in which an object's fields and collaborators are set by an external entity. In other words, objects are configured by an external entity. Dependency injection is an alternative to having the object configure itself. This might sound a bit vague, so let's look at a simple example.

After visiting the Packt Publishing website, you can search books by the author's name or different criteria. We'll look at the service that lists books by author.

The following interface defines book retrieval:

public interface BookService {
  List<Book> findAll();
}

The following class lists books by author names:

public class BookLister {

  private BookService bookFinder = new BookServiceImpl();
  
  public List<Book> findByAuthor(String author){
    List<Book> books = new ArrayList<>();
    
    for(Book aBook:bookFinder.findAll()){
      for(String anAuthor:aBook.getAuthors()){
        if(anAuthor.equals(author)){
          books.add(aBook);
          break;
        }
      }
    }
    
    return books;
  }
  
}

The BookLister class needs a BookService implementation; this means that the BookLister class depends on it. It cannot carry out its work without a BookService implementation. Therefore, BookLister has a dependency on the BookService interface and on some implementation of it. The BookLister class itself instantiates BookServiceImpl as its BookService implementation. Therefore, the BookLister class is said to satisfy its own dependencies. When a class satisfies its own dependencies, it automatically also depends on the classes it satisfies the dependencies with. In this case, BookLister now also depends on BookServiceImpl, and if any, on the other values passed as a parameter to the BookServiceImpl constructor. The BookService interface can have many implementations such as Spring JDBC-based data access and JPA-based data access implementation. We cannot use a different implementation of the BookService interface without changing the code.

To refactor this tight coupling, we can move the BookService instantiation to the constructor of the class. The following is the modified BookLister class:

public class BookLister {

  private final BookService bookFinder;
  
  public BookLister(BookService bookFinder) {
    this.bookFinder = bookFinder;
  }

  public List<Book> findByAuthor(String author){
    List<Book> books = new ArrayList<>();
    
    for(Book aBook:bookFinder.findAll()){
      for(String anAuthor:aBook.getAuthors()){
        if(anAuthor.equals(author)){
          books.add(aBook);
          break;
        }
      }
    }
    
    return books;
  }
  
}

Note that the BookService dependency is passed to the BookLister constructor as a constructor argument. Now, BookLister is only depending on BookService. Whoever instantiates the BookLister constructor will satisfy the dependency. The BookService dependency is said to be injected into the BookLister constructor, hence the term dependency injection. It is now possible to change the BookService implementation used by the BookLister class without changing the BookLister class.

There are two types of dependency injections:

A Spring configuration file creates/defines and configures (resolves dependencies) beans. In the Spring configuration file, the constructor injection is constructed as follows:

<bean id="bookLister" class="com.packt.di.BookLister">
  <constructor-arg ref="bookService"/>
</bean>
<bean id="bookService" class="com.packt.di.BookServiceImpl" />

The preceding code is equivalent to the following:

BookService service = new BookServiceImpl();
BookLister bookLister = new BookLister(service);

The setter injection is carried out by setting a property. In a setter injection, instead of passing bookService as a constructor argument, we change the class to pass as a setter method argument.

The Spring configuration is as follows:

<bean id="bookListerSetterInjection" class="com.packt.di.BookLister">
   <property name="bookService" ref="bookService" />
</bean>
  
<bean id="bookService" class="com.packt.di.BookServiceImpl" />

The preceding code snippet is equivalent to the following:

BookService service = new BookServiceImpl();
BookLister bookLister = new BookLister();
bookLister.setBookService(service);

The Spring IoC container is known as ApplicationContext. The objects that are used in our application, defined in ApplicationContext, and managed by the Spring IoC container are called beans; for example, bookService is a bean.

A bean is an object that is managed by the Spring IoC container; beans are created with the configuration metadata that you supply to the container, such as in the form of XML <bean/> definitions or using Java annotations.

A bean definition describes a bean instance. The bean definition contains the information called configuration metadata, which is needed by the container to know how to create the bean, the life cycle of the bean, and the dependencies of the bean.

The following properties are used to define a bean:

The following are the bean scopes:

The following are the steps in a bean's life cycle:

Note that a POJO doesn't need to depend on anything Spring-specific. For particular cases, Spring provides hooks in the form of these interfaces. Using them means introducing a dependency on Spring. The following figure depicts the bean's life cycle:

To learn more about DI and IoC, visit the Martin Fowler site at http://martinfowler.com/articles/injection.html.

In this section, we'll create a hello world example and set up the Eclipse environment for Spring. You can download the latest Eclipse version from http://www.eclipse.org/downloads/.

Note that Spring provides a specific Eclipse distribution for Spring, known as Spring Tool Suite (STS). STS is customized for developing Spring applications. You can download STS from http://spring.io/tools/sts.

Download the Spring 4.1.0 JAR from the Maven repository at http://search.maven.org/ or http://mvnrepository.com/artifact/org.springframework.

We read about the bean's life cycle; why don't we try to examine the life cycle?

Modify the HelloWorld class and implement the following Spring Framework interfaces:

Add the System.out.println statement in all the implemented methods. Now, add the following two methods:

  public void myInit() {
    System.out.println("custom myInit is called ");
  }

  public void myDestroy() {
    System.out.println("custom myDestroy is called ");
  } 

Modify the bean definition to call the init-method and destroy-method methods. The following is the modified bean definition:

  <bean id="helloWorld" class="com.packt.lifecycle.HelloWorld"
    init-method="myInit" destroy-method="myDestroy">
    <property name="message" value="Welcome to the Spring world">
    </property>
  </bean>

Now, modify HelloWorldExample to destroy the application context by registering to shutdown hook. The following is the modified code:

AbstractApplicationContext context = new  ClassPathXmlApplicationContext("applicationContext.xml");
  HelloWorld world = (HelloWorld) context.getBean("helloWorld");
  System.out.println(world.getMessage());
  context.registerShutdownHook();

When we run the application, the following output is displayed:

Note that the setBeanName method is invoked first, then the setBeanFactory, setApplicationContext, and afterProperiesSet methods are called, and then the custom init method is invoked. During destruction, the destroy method is called first and then the custom destroy-method is invoked.

The Spring container can autowire dependencies between the collaborating beans without using the <constructor-arg> and <property> elements that simplify the application context XML configuration.

The following autowiring modes can be used to instruct a Spring container to use autowiring for dependency injection:

Let's modify our HelloWorld example and try wiring by name:

    <bean name="message" class="java.lang.String">
       <constructor-arg value="auto wired" />
    </bean>
    
   <bean id="helloWorld" class="com.packt.lifecycle.HelloWorld" autowire="byName">
    </bean>

It will print auto wired.

Spring provides annotations to wire collaborators. The following are the annotations:

To enable autowiring through an annotation, the application context needs to be configured to indicate the annotation. Add the following entry to the application context:

<context:annotation-config/>

Modify the application context to enable an annotation:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:context="http://www.springframework.org/schema/context"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
    http://www.springframework.org/schema/context
    http://www.springframework.org/schema/context/spring-context-3.0.xsd">

<context:annotation-config/> 
   <bean name="message" id="message" class="java.lang.String">
       <constructor-arg value="auto wired" />
    </bean>
    
    <bean id="helloWorld" class="com.packt.lifecycle.HelloWorld">
    </bean>
       
</beans>

Modify the HelloWorld class to annotate the setter method (setMessage) or the private message property with @Autowired:

public class HelloWorld implements ApplicationContextAware,BeanNameAware, InitializingBean,
    BeanFactoryAware,BeanPostProcessor,  DisposableBean {

  private String message;

  public String getMessage() {
    return message;
  }
  
  @Autowired
  public void setMessage(String message) {
    this.message = message;
  }
     //code omitted for brevity
}

Rerun the application; you will see the auto wired message.

AOP is one of the key components of Spring Framework. Object-oriented programming fails to deal with technical and functional cross-cutting concerns, such as generic functionalities that are needed in many places in our application.

The following are a few examples of cross-cutting concerns:

In our application, we need logging to debug or troubleshoot, so we put debug messages in every method; this is a cross-cutting concern. Similarly, we secure methods for unauthorized access.

AOP overlays a new layer onto the data-driven composition of OOP. This layer corresponds to the cross-cutting functionalities that are difficult to integrate through the OOP paradigm.

AOP is implemented with AspectJ and Spring AOP:

The following example demonstrates a cross-cutting concern:

class Account{
  private double balance;
  public void withdraw(double amount){
    logger.debug("Withdraw –"+amount);
    tx.begin();
      balance = this.balance-amount;
      accountDao.saveBalance(balance);
    tx.commit();
  }
}

The withdraw method logs debug information, begins a transaction, performs a database transaction, and finally commits the transaction. In each method, we will introduce duplicate code for debugging and opening and committing a transaction. These are cross-cutting concerns as the conceptually duplicate code will be scattered to all modules in the application. This is bad in the sense that if we need to change any settings, we have to manually change all methods in all modules, such as instead of logger.debug, and if we need to change the logging to logger.info, we need to modify all methods.

Before we dig deep into AOP, let's get familiar with the terminology:

There are two types of AOP:

Spring AOP is based on proxies. To know more about proxies, read about the proxy pattern or visit http://en.wikipedia.org/wiki/Proxy_pattern.

We'll display Hello World! through AOP. The following are the steps to create the hello world message:

When we run the program, the MessageDecorator around advice is applied on the proxy object. When proxy.writeMessage is called, the correct output is displayed.

The Spring Data Access Object (DAO) support makes it easy to work with data access technologies such as JDBC, Hibernate, or JDO in a standardized way. Spring Framework provides APIs to reduce JDBC code duplication. Spring JDBC hides the low-level details and allows us to concentrate on business logic, which makes switching between databases easy and simple.

In a normal JDBC code, we catch a series of checked exceptions such as SQLException while acquiring a connection or executing a SQL statement; with Spring, we can code without worrying about catching exceptions, as Spring does the exception handling for us. Spring is not throwing away or eating the checked exceptions but is instead translating them to unchecked/runtime ones.

Spring provides a set of abstract DAO classes that one can extend; these abstract classes have methods to provide the data source and any other configuration settings that are specific to the technology one is currently using.

The following are the DAO support classes:

In normal JDBC code, we write the code in the following way to access the database:

Spring Framework relaxes the requirement to write numerous JDBC code lines. We need to write only the code to perform the following:

Spring takes care of all the grungy, low-level details that can make JDBC such a tedious API to develop against.

The Spring-JDBC abstraction framework consists of four different packages:

The org.springframework.jdbc.core package contains the following:

The org.springframework.jdbc.datasource package contains the following classes:

The org.springframework.jdbc.object package contains the following:

The org.springframework.jdbc.support package contains the following:

The JdbcTemplate class is the main class in the org.springframework.jdbc.core package. It simplifies the use of JDBC since it handles the creation and release of resources. This helps avoid common errors such as not closing the connection, and it executes the core JDBC workflow such as statement creation and execution leaving application code to provide SQL and extract results.

We'll build a phone book application and store phone numbers using Spring JDBC and normal JDBC and realize the simplicity and usability of Spring JDBC. We'll use the Apache Derby database for persistence. Derby can be downloaded from http://db.apache.org/derby/.

You can use better built-in databases such as H2. It has more features and less restriction than Derby. However, we're using Derby for simplicity.

The following are the steps to run Derby:

Download the latest version of the Spring JDBC JAR and its dependencies from http://maven.springframework.org/release/org/springframework/spring/.

Perform the following steps to implement Spring JDBC and simplify the code:

Spring Framework provides supports for transaction management. The following are characteristics of the Spring transaction management framework:

Two transaction management options are available for the J2EE developers. The following are the two options:

Both transaction models have downsides. The global transaction needs an application server and JNDI to manage transactions; it uses JTA but the JTA API is cumbersome and has a complex exception model. The need for an application server, JNDI, and JTA limits the reusability of code.

The local transactions have the following disadvantages:

Spring's transaction model solves the problems associated with the global and local transactions, and it offers a consistent programming model for developers that can be used in any environment.

Spring Framework supports both declarative and programmatic transaction management. Declarative transaction management is the recommended one, and it has been well accepted by the development community.

The programmatic transaction model provides an abstraction that can be run over any underlying transaction infrastructure. The concept of transaction strategy is the key to the transaction abstraction. The org.springframework.transaction.PlatformTransactionManager interface defines the strategy.

The following is the PlatformTransactionManager interface:

public interface PlatformTransactionManager {
    TransactionStatus getTransaction(
    TransactionDefinition definition) throws TransactionException;
    void commit(TransactionStatus status) throws 
                                         TransactionException;
    void rollback(TransactionStatus status) throws 
                                         TransactionException;
}

The following are the characteristics of PlatformTransactionManager:

The TransactionDefinition interface defines the following:

public interface TransactionDefinition {
   int getIsolationLevel();
   int getPropagationBehavior();
   String getName();
   int getTimeout();
   boolean isReadOnly();
}

The TransactionStatus interface provides a simple way for transactional code to control the transaction execution and query the transaction status; it has the following signature:

public interface TransactionStatus {
    boolean isNewTransaction();
    void setRollbackOnly();
    boolean isRollbackOnly();
}

The PlatformTransactionManager implementations normally require knowledge of the environment in which they work, such as JDBC, JTA, Hibernate, and so on.

A local PlatformTransactionManager implementation defines a JDBC data source and then uses the Spring DataSourceTransactionManager class, which gives it a reference to DataSource. The following Spring context defines a local transaction manager:

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> 
  <property name="driverClassName" value="${jdbc.driverClassName}" /> 
  <property name="url" value="${jdbc.url}" /> 
  <property name="username" value="${jdbc.username}" /> 
  <property name="password" value="${jdbc.password}" /> 
</bean>

Here, ${jdbc.xxxx} represents the values defined in the properties file. Usually, the convention is that the JDBC properties are defined in a properties file that is then loaded from applicationContext, and then the JDBC properties are accessed using the key such as ${key}. The following is the XML configuration of transaction manager:

<bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> 
  <property name="dataSource" ref="dataSource"/> 
</bean>

When we use JTA in a J2EE container and use a container DataSource obtained via the JNDI lookup, in conjunction with Spring's JtaTransactionManager, then JtaTransactionManager doesn't need to know about DataSource, or any other specific resources, as it will use the container's global transaction management infrastructure.

The following is the JtaTransactionManager definition in Spring context:

<jee:jndi-lookup id="dataSource" jndi-name="myDataSource "/> 
<bean id="txManager" class="org.springframework.transaction.jta.JtaTransactionManager"/> 

The benefit of Spring transaction manager is that in all cases, the application code will not need to change at all. We can change how transactions are managed merely by changing the configuration, even if that change means moving from local to global transactions or vice versa.

Declarative transaction management is preferred by most users; it is the option with the least impact on the application code. It is most consistent with the ideals of a non-invasive lightweight container. Spring's declarative transaction management is made possible with Spring AOP.

The similarities between the EJB CMT and Spring declarative transaction are as follows:

@Transactional(readOnly = true) 
public class FooServiceImpl implements FooService { 
    public Foo getFoo(String fooName) { 
        
    } 
    // This settings has precedence for this method 
    @Transactional(readOnly = false, propagation = 
      Propagation.REQUIRES_NEW) 
    public void updateFoo(Foo foo) { 
    } 
}

Object result = transTemplate.execute(new TransactionCallback() { 
    public Object doInTransaction(TransactionStatus status) { 
        updateOperation(); 
        return resultOfUpdateOperation(); 
    } 
});

transTemplate.execute(new TransactionCallbackWithoutResult() { 
protected void doInTransactionWithoutResult(
                            TransactionStatus status) { 
        updateOperation1(); 
        updateOperation2(); 
    } 
});

DefaultTransactionDefinition def = new DefaultTransactionDefinition();
def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
TransactionStatus status = txManager.getTransaction(def);
try {
    // execute your business logic here
} catch (Exception ex) {
    txManager.rollback(status);
    throw ex;
}
txManager.commit(status);

The Model View Controller (MVC) is a widely used web development pattern. The MVC pattern defines three interconnected components, namely model, view, and controller.

The model represents the application data, logic, or business rules.

The view is a representation of information or a model. A model can have multiple views, for example, marks of a student can be represented in a tabular format or graphical chart.

The controller accepts client requests and initiates commands to either update the model or change the view.

The controller controls the flow of the application. In JEE applications, a controller is usually implemented as a servlet. A controller servlet intercepts requests and then maps each request to an appropriate handler resource. In this section, we will build a classic MVC front controller servlet to redirect requests to views.

Spring MVC is a web application framework that takes advantage of Spring design principles:

Spring MVC is used for the following advantages:

In Spring MVC, the following is a simplified request-handling mechanism:

The following sequence diagram represents the flow and interaction of Spring MVC components:

We will build a Spring web application and unit test code using JUnit by performing the following steps:

Resources: Spring Framework Reference Documentation

This chapter covered the Spring basics. It discussed the Spring projects and in particular Spring Framework. It explored the Spring container, Spring bean life cycle, dependency injection, AOP, Spring MVC, and Spring transaction management.

The next chapter will focus on getting the reader quickly started with JUnit 4 and the Mocking framework. It provides an overview of JUnit testing and explores the Mockito APIs.