Testing Database Code Using JUnit

This post outlines the basic setup that you may need to use HSQL in JUnit, Spring, Maven environment to test database code when you are using JdbcTemplate directly instead of Hibernate.

Step 1: Include the maven dependencies in your pom:

<dependency>
    <groupId>hsqldb</groupId>
    <artifactId>hsqldb</artifactId>
    <version>1.8.0.7</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>commons-collections</groupId>
    <artifactId>commons-collections</artifactId>
    <version>3.2</version>
</dependency>
<dependency>
    <groupId>commons-dbcp</groupId>
    <artifactId>commons-dbcp</artifactId>
    <version>1.2.2</version>
</dependency>

Step 2: Setup bean config that will be used by our test (save as database.xml and put it in the resources folder):

<bean id="dataSource"
        class="org.apache.commons.dbcp.BasicDataSource">
    <property name="driverClassName" 
        value="org.hsqldb.jdbcDriver"/>
    <property name="url" 
        value="jdbc:hsqldb:mem:aname"/>
    <property name="username" value="sa"/>
    <property name="password" value=""/>
    <property name="defaultAutoCommit" value="false"/>
</bean>
<bean id="jdbcTemplate" 
        class="org.springframework.jdbc.core.JdbcTemplate">
    <property name="dataSource" ref="dataSource"/>
</bean>

Step 3: Write the test case(s)

You may find the HSQL documentation (supported data types in chapter 9) and the api doc on JdbcTemplate useful as well.

Of course things will not be that simple due to one simple reason: HSQL will most probably not support all the data types used by your DB (e.g. "bytea" , an array of bytes, is supported by PostGreSQL DB but not by HSQL). But it definitely a headstart and a good way to test your DB.

Caching Method Invocation Results

Worked on setting up a cache for a method invocation fetching results from a webservice using Spring Cache AOP and EHCache in a Spring-Maven environment.Long live sourceforge! The spring cache java doc is pretty helpful and this article by Pieter Coucke expands on what you read in the java doc. You can also have a look at my complete configuration (which works) and is based on the article and the java doc.

And if you are using Maven, you would need to add dependencies for ehcache and spring cache.

<dependency>
    <groupId>net.sf.ehcache</groupId>
    <artifactId>ehcache</artifactId>
    <version>1.5.0</version>
</dependency>
<dependency>
    <groupId>spring-cache</groupId>
    <artifactId>spring-cache</artifactId>
    <version>2.4.1</version>
</dependency>

Using JAXB in a Spring-Maven Environment for WebServices

In a Spring application you can consume a webservice using JaxRpcPortProxyFactorybean or XFireClientFactoryBean (in conjunction with XFire). However, there is another way which can prove to be extremely useful and convenient if you are using Spring and Maven: by using Spring and Maven in conjunction with JAXB. As usual, I will focus on using JAXB and not about JAXB. To learn more about JAXB see:

JAXB Reference at Sun

In this article we will cover

1. Setting up JAXB in Spring environment to generate stubs for the webservice

2. Using it in an external project or the same project.

As per the default maven build structure, you need to make a package called "wsdl" under src/main and place a copy of wsdl of the webservice you wish to use. Then configure your pom file with the right dependencies:

POM config for JAXB

Two things that you should notice in the pom besides JAXB dependencies are the build plugins maven-source-plugin and maven-jaxb2-plugin. They will generate stubs for your webservice in the "target" directory under "generated-sources" when you compile the project/ generate resources using maven. After that your webservice should be ready to used. Almost :D.

The generated source will contain stubs that correspond to exposed functions, responses and the various objects used. The name of the stubs will correspond to name in wsdl. In the same project you can use it by importing stubs from the package specified in com.saveenkumar.myApp.someWebService.types.  For an external project, you just need to import the project as a dependency.

Let us now see how to use these stubs. You will be able to use the webservice in your Spring app with the help of org.springframework.ws.client.core.WebServiceTemplate. You can see the bean config that you can use to inject it here:

WebServiceTemplate config as a spring bean

Note that the "contextPaths" property of the JAXB marshaller is same as the  property above. If you want to dig still deeper, have a look about using WebServiceTemplate  at:

WebServiceTemplate Reference

and

WebServiceTemplate API

It may be a good idea to hide the WebServiceTemplate behind a nice interface to abstract away the user from the generated JAXB classes.

The generated classes will always have a class called "ObjectFactory". There will also be objects corresponding to every operation, every response and every object used in these transactions. Let us say our webservice exposes the following operations:

List getAllStockInfo();

List getStocksByVolatilityRange(float low, float high);

StockInfo getStockInfo(String ticker);

May generate following objects:

ObjectFactory

ArrayOfStockInfo

StockInfo

GetAllStockInfo

GetAllStockInfoResponse

GetStockInfo

GetStockInfoResponse

GetStocksByVolatilityRange

GetStocksByVolatilityRangeResponse

Let us say we want to use GetStockInfo. The code would look something like:

Sample JAXB Usage

I would also recommend using SoapUI to test your webservices. 

Persisting A List of Custom Objects Using Hibernate in a Spring Env.

The prospect of persisting an object using hibernate into a database and then reading it back did not seem challenging with good old hibernate taking care of most things. 

Piece of cake? Not quite actually as I discovered while trying to do it for a List of custom objects. Let us see what were the challenges and how I found the solutions. Let us assume I wish to persist an object that contains the current situation of all stocks trading in the market. Our simplistic object has an id and a list of stocks: 

StockInfoHolder POJO

The list of stocks is made of a custom object:

StockInfo POJO

And since we refuse to live without spring, we need some bean config:

Spring Bean Config

With spring so near how can we forget maven and the pom dependencies:

POM Dependencies

Phew! Sometimes I forget how much these XML config make our lives easier (?).  Now, had it been my own custom object, I would have used @Embedded. But what do I do with a java collection. I was tempted to mark it with @Lob and it compiled fine. But when I actually tried to persist it, it gave me one big, fat ClassCastException: java.util.ArrayList cannot be cast to java.sql.Blob. OK, so objects don't turn into byte arrays overnight and that attempt was dumb and desperate. 

Then what? Referring "Java Persistence with Hibernate" (Bauer and King,2006) and official hibernate docs helped my to make my classes look like this:

Hibernate Ready StockInfoHolder

Hibernate Ready StockInfo

Now this works like a charm: at least the part about starting your app, seeing your tables created perfectly and storing your objects at the right place with some class like:

HibernateDao 

In our next post we will see how we read this information back and use it if I face any difficulty with it as well!

Running ActiveMQ Broker in Spring

ActiveMQ can run as an independent JMS server. This may be desirable if we want to run it independently of our spring application. However it is also possible that we may want to deploy a message broker within a spring environment. This may be simply because we need to do some unit testing or because our webapp is too small to break across several machines. Whatever be the reason. Let us make a note of basic steps to do it:

1. Put in your activemq.xml under the WEB-INF folder. Your ActiveMQ distribution(5.1.0 at time of this article) has this config file under the "conf" folder. We will not discuss configuring it here. Go here to read about configuring

2. The lib folder of the distribution has all possible jars that JMS may ever need in its lifetime. If you are not using Maven, you may need to copy the jars to your classpath. If you are using Maven, these dependencies should generally suffice for basic use.

        <dependency>
           <groupId>org.springframework</groupId>
           <artifactId>spring-jms</artifactId>
           <version>2.5.5</version>
       </dependency>

       <dependency>
           <groupId>org.apache.derby</groupId>
           <artifactId>derby</artifactId>
           <version>10.3.1.4</version>
       </dependency>

       <dependency>
           <groupId>org.apache.activemq</groupId>
           <artifactId>activemq-all</artifactId>
           <version>5.1.0</version>
       </dependency>

       <dependency>
           <groupId>org.apache.activemq</groupId>
           <artifactId>activemq-web</artifactId>
           <version>5.1.0</version>
       </dependency>

Go here if you wish to simply run ActiveMQ using Maven

3. Put this bean definition in your spring conf:

<bean id="broker" class="org.apache.activemq.xbean.BrokerFactoryBean">
   <property name="config" value="/WEB-INF/activemq.xml"/>
   <property name="start" value="true"/>
</bean>

You should be good to go. Bringing up your Spring application will start the broker at tcp://localhost:61636

Setting up Quartz in a Spring-MySQL Environment

If you are using a persistent JobStore in Quartz, you will have to back your spring application with a DB. MySQL can be pretty convenient for local unit testing. Besides the regular spring DataSource config, you need a few more things here and there. I did not find any comprehensive "todo" checklist for MySQL online. So summing up what worked for me.

Using SchedularFactoryBean you can specify a MySQL DataSource and fine-tune it using quartz properties. You can see this in a config file I had published earlier:

XML Config

Besides this, you need to have the following dependencies for sure in your pom if you are using Maven:

POM dependencies

If you are not using maven, the corresponding jars should be in the classpath.

Finally, don't forget to run the SQL script to create tables in your database provided by quartz:

Creating DB Tables for Quartz

Using Autowiring for Testing RMI Services in Spring

Scehduling can be a common requirement in many applications. However testing such an application that used RMI with JUnit and JMock in a Spring-Maven environment turned out to be a little tricky for me. Thanks to the help of a colleague (thanks Mudassir!) and some head banging, I was able to find a way: Autowiring.

Generally my basic JUnit test cases have the following features:
1. The whole class annotated by @RunWith(JMock.class) - org.junit.runner.RunWith;
2. A set up method (the init method) annotated with @Before - org.junit.Before
3. The test cases annotated @Test - org.junit.Test
4. JUnit4Mockery used to mock relevant interfaces - org.jmock.integration.junit4.JUnit4Mockery
5. The usual expectatons and assertions
6. Spring adds punch with ability to mock request, response, sessions - org.springframework.mock.web.*

A Simple Test Case

Works fine for most things. Now picture this: you are developing application that needs to check stock prices every five minutes and send alerts to registered users if need be. Lets say there are three modules being developed for it: the user interface using which a user may register for an alert for stock price, the scheduler that keeps track of these alerts and the workflow engine that takes care of the alerts once fired. A classic MVC approach so far.

The controller accepts alerts from user interface and schedules Jobs that forward all information to the workflow. Let us assume these three modules are being developed by three different teams sitting in three corners of the world (ok, may be three corners of the office or just three different/independent machines/servers).

Now, when you are making the controller, you are essentially dependent on view for input and on the model for feedback (if any) for your input. We can provide access to our controller using any RMI strategy. For our example, we consider Spring's HttpInvoker. We intend to write a a test case to test the controller module.

Our controller has a remote service running in a spring environment. If it had been a simple servlet listening to ordinary post/get requests, writing a test case with MockHttpRequest would be a piece of cake. However when it is an RMI service, what mock up to use? An answer can be a test class looking something like this:

A Test Case For RMI Service


The answer lies in using SpringJUnit4ClassRunner and then auto-wiring the HttpInvokerService. ContextConfiguration points to the locations for the config xml. In the current case you should put it in "myPackage. If you are using Maven, the resources folder would be the right place to put it. The config file may look like:

Autowiring Config


If you are using Maven, don't forget to add the following dependencies:

Maven Dependencies

A few tweaks may be needed to suit your case but this should give you a general idea about using autowiring for your test cases in JUnit, JMock, Spring, Maven environment.

Maven Blues

Was facing a strange problem where Maven (version 2) would say something like "generics are not supported in -source 1.3" for Java 5 features. Adding the following the Plugins element in the pom helped:

<plugins>
  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>2.0.2</version>
    <configuration>
      <source>1.5</source>
      <target>1.5</target>
    </configuration>
  </plugin>
<plugins>

Splitting a Project into Modules in Maven

The beauty of Maven and Idea is the ease with which they allow you to manage, build and test your applications. Let us suppose we have a project that we wish to build in modules. For sake of simplicity we assume that the project has two basic modules: a webapp module and a core module.

Make a folder on the system for your project. In the folder make two folders by name "core" and "webapp". Also put a pom.xml which should look like:

parent pom

Notable things are the modules node and that the packaging is pom.

In the "core" folder make a folder "src" and put a pom.xml something like:

core pom

Main things to note about the pom is that packaging is "jar". ID are same as those in the parent pom. In "src" folder make two folders "main" and "test". Put a folder named "java" in each of them.

In the "webapp" folder create same directory structure as "core". The pom.xml here would look like:

webapp pom

Make the directory structure webapp -> src -> main -> webapp -> WEB-INF
in WEB-INF put in a web.xml file

You are good to go now. Now all you need to do is mvn idea:idea or mvn eclipse:eclipse (depending on what you are using) while being in the main folder to create the project with its modules.