Sample Code

JPetStore 6 is a full web application built on top of MyBatis 3, Spring 3 and Stripes. It is available for download in the downloads section of MyBatis project site. In this section we will walk through this sample to understand how is it built and learn how to run it.


This new JPetStore comes with the same idea in mind than its predecessors: keep it simple. The purpose of JPetStore 6 is to demonstrate how to build a web application with very few classes and no advanced coding skills. You just need to know plain Java and SQL.

The 6th version of JPetStore is the smallest of the family, 20% smaller than its predecessor. It uses just 24 java classes while keeping a good design and program structure.

eduardo@nomada ~ $ ./ ~/git/jpetstore-6/src/main/
      60 text files.
      60 unique files.                              
       3 files ignored. v 1.60  T=0.28 s (209.8 files/s, 17722.9 lines/s)
Language                     files          blank        comment           code
Java                            24            480            462           1429
JSP                             20            148              0            984
XML                              9             79            120            405
CSS                              1             46              0            277
SQL                              2             26             30            226
HTML                             2             44              0            143
SUM:                            58            823            612           3464

As we will see later on, you will find no code to deal with JDBC, to create objects or bind them or to handle transactions. What is more impressive is that you will not find any call to the MyBatis API. Although this sounds magical, you will see that the combination of MyBatis mappers and dependency injection lets you build applications without dependencies.

Program Structure

JPetStore 6 follows the typical maven project structure

/jpetstore                    <-- Maven pom.xml goes here.
      /java                   <-- Java code goes here.
              /domain         <-- Business domain objects go here.
              /persistence    <-- Mapper interfaces go here.
              /service        <-- Application logic goes here.
                /actions      <-- Presentation logic (actions) goes here.
      /resources              <-- Non java files go here.
              /persistence    <-- Mapper XML files go here.
        /WEB-INF              <-- web.xml and applicationContext.xml go here.
          /jsp                <-- JSP files go here.

Configuration files

Configuration files are read during application startup. Their purpose is to configure the three frameworks composing the application: Stripes, Spring and MyBatis. We will need to configure just two files: web.xml and applicationContext.xml.


First of all we need to start Stripes, so we will follow the Stripes manual to do so. The manual says that we should set up a dispatcher servlet and a filter, so let's go:

  <display-name>Stripes Filter</display-name>

Stripes is able to search for ActionBean classes, for that purpose we must set up the base package it should search in.


We are done with Stripes. Let's move on to the Spring side. According to Spring's reference manual we should add a Context listener to start up Spring. Let's add it:


By default Spring will use /WEB-INF/applicationContext.xml if we don't specify a different file. The default is fine for us.

Now we have to let Stripes know that it will be running with Spring. This way we will be able to inject Spring beans directly into Stripes ActionBeans. For that purpose, following once again the Stripes manual, we set up an interceptor as follows below:


We are done with web.xml. As you may have noticed, we have not set up any MyBatis 3 configuration yet. That configuration goes into the Spring's applicationContext.xml that we will see in the following section.


As you already know, applicationContext.xml is the Spring's configuration file. Spring is a dependency injection framework and it has to know which beans it must create and how to bind them together and that is what applicationContext.xml file is for. Let's have a deeper look into it.

The first and easiest thing we have to do is let Spring know where are our service beans. We will let Spring search them in our classpath so we just need to provide it the base package to search in:

<context:component-scan base-package="org.mybatis.jpetstore.service" />

NOTE Spring's component scan feature is not able to find MyBatis mappers. A mapper is not a plain bean and Spring would not know how to instantiate it. We will see how to search for mappers soon.

We will also need a DataSource and a TransactionManager. Given that this is a demo application we will use a test Spring DataSource that will create an HSQL in-memory database and load our database scripts into it and the standard Spring's DataSourceTransactionManager to handle transactions.

<jdbc:embedded-database id="dataSource">
  <jdbc:script location="classpath:database/jpetstore-hsqldb-schema.sql"/>
  <jdbc:script location="classpath:database/jpetstore-hsqldb-dataload.sql"/>

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

So far, all we have done is standard Stripes and Spring configuration and now it is time to move on to the MyBatis part. As you have learned in this manual to set up MyBatis with Spring you need at least two things: an SqlSessionFactoryBean and, at least, one mapper class. So let's go hands on. First define a SqlSessionFactoryBean:

<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
  <property name="dataSource" ref="dataSource" />

And now we need to setup our mappers. For that purpose we will use the MapperScannerConfigurer that works similar to Spring standard component scan. It will search our classpath for mapper classes and register them to MyBatis. Similar to Spring's component scan we must configure the base package to search in.

<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
  <property name="basePackage" value="org.mybatis.jpetstore.persistence" />

To save some writing when building our mapper xml files we would want to be able to use short aliases for beans. The SqlSessionFactoryBean has the capability to search for beans and register their short names as aliases if we setup the typeAliasPackage property like the following:

<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
  <property name="dataSource" ref="dataSource" />
  <property name="typeAliasesPackage" value="org.mybatis.jpetstore.domain" />

Our application is now fully configured and ready to run. But before running it lets have a tour through the code to see how it looks like.

Code tour

JPetStore 6 is a typical MVC application with three layers: presentation, logic and data access.


The presentation layer is composed by JSP files and Stripes ActionBeans. JSPs just use plain HTML, JSTL tags and Stripes tags. Stripes ActionBeans are like Struts actions or Spring MVC controllers.

Given that we have integrated Stripes with Spring, we can inject our services into our ActionsBeans so you can just use them without caring about its creation or lookup. Have a look at CatalogActionBean:

public class CatalogActionBean extends AbstractActionBean {
  private transient CatalogService catalogService;
  public ForwardResolution viewCategory() {
    if (categoryId != null) {
      productList = catalogService.getProductListByCategory(categoryId);
      category = catalogService.getCategory(categoryId);
    return new ForwardResolution(VIEW_CATEGORY);

The @SpringBean annotation is an Stripes annotation that tells Stripes to look for that bean in Spring and inject it into this ActionBean.


Application logic is composed by plain Java beans that act as services and plain Java beans that act as domain objects. This layer is in charge of filling domain objects with database data and updating database data with the content of the domain objects. For this purpose this layer must be transactional.

Let's have a look at OrderService code to see how all this is achieved:

public class OrderService {

  private ItemMapper itemMapper;
  private OrderMapper orderMapper;
  private LineItemMapper lineItemMapper;

  public void insertOrder(Order order) {
    for (int i = 0; i < order.getLineItems().size(); i++) {
      LineItem lineItem = (LineItem) order.getLineItems().get(i);
      String itemId = lineItem.getItemId();
      Integer increment = new Integer(lineItem.getQuantity());
      Map<String, Object> param = new HashMap<String, Object>(2);
      param.put("itemId", itemId);
      param.put("increment", increment);

    for (int i = 0; i < order.getLineItems().size(); i++) {
      LineItem lineItem = (LineItem) order.getLineItems().get(i);

The first thing you will notice is that there is no JDBC code in the service, nor it is any MyBatis code in it. You may think that we used the DAO pattern and database access code is in the database layer, but as we will see later, the database layer is built with MyBatis mappers, that are plain java interfaces, and that is why you will not find any call to MyBatis API in the whole application. It is just not needed.

The second thing you may have noticed is that there are no commits or rollbacks. That is because it uses the declarative transaction demarcation feature of Spring that is fully supported by MyBatis-Spring. The Spring's @Transactional annotation indicates that this method is transactional, that means that all updateInventoryQuantity, insertOrder and insertLineItem mapper calls must end OK. If one of them fails any previous update will be rolled back.


The persistence layer is composed of MyBatis mappers. Mappers are just plain Java interfaces and mapper XML files containing the SQL statements. There is no custom Java code in this layer. When the getOrder method is called on the OrderMapper interface, MyBatis will execute the getOrder SQL statement in OrderMapper.xml file and will populate the Order domain bean with retrieved data.

public interface OrderMapper {
  List<Order> getOrdersByUsername(String username);
  Order getOrder(int orderId);
  void insertOrder(Order order);
  void insertOrderStatus(Order order);
<mapper namespace="org.mybatis.jpetstore.persistence.OrderMapper">

  <cache />

  <select id="getOrder" resultType="Order">
      BILLADDR1 AS billAddress1,
      BILLADDR2 AS billAddress2,
      SHIPADDR1 AS shipAddress1,
      SHIPADDR2 AS shipAddress2,
      EXPRDATE AS expiryDate,
      USERID AS username,

NOTE You can easily add caching to your queries by adding a <cache /> element to your mapper xml file.

Running JPetStore

You may ask. Does all this work? Yes it does! Let's run it.

Let's assume you have a clean computer. These are the steps you should follow to have the sample running on Tomcat with Eclipse:

  • Download and install a JDK 6 or later
  • Download and upzip Eclipse
  • Download and unzip Tomcat
  • Run Eclipse
  • Go to Git tab
  • Clone the repo
  • Select working directory, right click and select Import Projects (general)
  • Go to Java EE tab
  • Right click on jpetstore project and select "Configure/Convert to Maven Project"
  • Right click on jpetstore project and select "run on server"
  • Select Tomcat Server and set your installation directory
  • JPetStore home page should be shown!!

Now you are ready to play with it, experiment with your own changes or whatever you want.

And remember that if you find a bug or something that is missing or can be improved (for example the missing tests!), fork the repo, change it, and open a pull request. Thanks in advance!!!

NOTE JPetStore 6 should run in any Servlet 2.5 y JSP 2.1 compliant Java server. Eclipse is not needed either, you can run the sample from your favorite IDE or the command line.