Integration Testing for Spring Applications with JNDI Connection Pools


We all know we need to use connection pools where ever we connect to a database. All of the modern drivers using JDBC type 4 supports it. In this post we will have look at an overview of connection pooling in spring applications and how to deal with same context in a non JEE enviorements (like tests). 

Most examples of connecting to database in spring is done using DriverManagerDataSource. If you don't read the documentation properly then you are going to miss a very important point.

NOTE: This class is not an actual connection pool; it does not actually pool Connections. It just serves as simple replacement for a full-blown connection pool, implementing the same standard interface, but creating new Connections on every call.
Useful for test or standalone environments outside of a J2EE container, either as a DataSource bean in a corresponding ApplicationContext or in conjunction with a simple JNDI environment. Pool-assuming Connection.close() calls will simply close the Connection, so any DataSource-aware persistence code should work.

Yes, by default the spring applications does not use pooled connections. There are two ways to implement the connection pooling. Depending on who is managing the pool. If you are running in a JEE environment, then it is prefered use the container for it. In a non-JEE setup there are libraries which will help the application to manage the connection pools. Lets discuss them in bit detail below.

1. Server (Container) managed connection pool (Using JNDI)


When the application connects to the database server, establishing the physical actual connection takes much more than the execution of the scripts. Connection pooling is a technique that was pioneered by database vendors to allow multiple clients to share a cached set of connection objects that provide access to a database resource. The JavaWorld article gives a good overview about this.



In a J2EE container, it is recommended to use a JNDI DataSource provided by the container. Such a DataSource can be exposed as a DataSource bean in a Spring ApplicationContext via JndiObjectFactoryBean, for seamless switching to and from a local DataSource bean like this class.



The below articles helped me in setting up the data source in JBoss AS.


Next step is to use these connections created by the server from the application. As mentioned in the documentation you can use the JndiObjectFactoryBean for this. It is as simple as below



If you want to write any tests using springs "SpringJUnit4ClassRunner" it can't load the context becuase the JNDI resource will not be available.

For tests, you can then either set up a mock JNDI environment through Spring's SimpleNamingContextBuilder, or switch the bean definition to a local DataSource (which is simpler and thus recommended). 

As I was looking for a good solutions to this problem (I did not want a separate context for tests) this SO answer helped me. It sort of uses the various tips given in the Javadoc to good effect. The issue with the above solution is the repetition of code to create the JNDI connections. I have solved it using a customized runner SpringWithJNDIRunner. This class adds the JNDI capabilities to the SpringJUnit4ClassRunner. It reads the data source from "test-datasource.xml" file in the class path and binds it to the JNDI resource with name "java:/my-ds". After the execution of this code the JNDI resource is available for the spring container to consume.



To use this runner you just need to use the annotation @RunWith(SpringWithJNDIRunner.class) in your test. This class extends SpringJUnit4ClassRunner beacuse a there can only be one class in the @RunWith annotation. The JNDI is created only once is a test cycle. This class provides a clean solution to the problem.

2. Application managed connection pool

If you need a "real" connection pool outside of a J2EE container, consider Apache's Jakarta Commons DBCP or C3P0. Commons DBCP's BasicDataSource and C3P0's ComboPooledDataSource are full connection pool beans, supporting the same basic properties as this class plus specific settings (such as minimal/maximal pool size etc).

Below user guides can help you configure this.


The below articles speaks about the general guidelines and best practices in configuring the connection pools.



Note:- All the text in italics are copied from the spring documentation of the DriverManagerDataSource.

TalkNotes - The story of SonarQube told to a DevOps Engineer


This week I spoke at Bangalore DevOps meetup on the topic "The story of SonarQube told to a DevOps Engineer". I have started writing TalkNotes inspired from Martin Fowler.Unlike his detailed article my posts aims to help the audience better understand my slides. SonarQube is a open source code quality management platform. It was a 30 mins talk focused at the need, setup, CI Infrastructure and administration of the SonarQube to the DevOps community.


I have started the talk with one of my favorite subject Technical Debt. We have also looked at some of the parameters which determines the quality are coding standards breach, duplication, lack of unit tests, bad distribution of complexity, Spaghetti Design etc... I have spoke about this in more detail at previous post. There are various existing tools that helps reduce the technical debt by improve the code quality. What was missing was a easier way of tracking these code rule violations. For examples I need to know how much debt was introduced or was cleaned up? As a developer how do you quantify improvement the which a particular code refactoring has brought to the team etc..

This is where Sonar come to your help. Sonar's rich feature set allows you to do these and more. Currently it can run the quality analysis on more than 20 languages including Java, C#, C/C++, PL/SQL, Javascript, PHP, Web, XML etc.... It stores the analysis results and the data is displayed through various dashboards. Further slides discusses the sonar platform overview and installation.

The below diagram shows the CI environment including SonarQube. The Hudson plugin for SonarQube can be configured by following the wiki.


Image Idea from this blog.

The best part of sonar is its documentation. This was the most comprehensive documentation I have read about any open source product. You just need their wiki page to get 99% of answers. Now that I have it configured hope to write more about it in the coming moths.