1. Overview
Typically, when testing an application that uses JNDI, we may want to use a mocked datasource instead of a real one. This is a common practice when testing in order to make our unit tests simple and fully separated from any external context.
In this tutorial, we’ll showcase how to test a mock JNDI datasource using the Spring Framework and the Simple-JNDI library.
Throughout this tutorial, we’re only going to focus on unit tests. But be sure to check out our article on how to create a Spring application using JPA with a JNDI datasource.
2. Quick JNDI Recap
In short, JNDI binds logical names to external resources like database connections. The main idea is that the application doesn’t have to know anything about the defined datasource except its JNDI name.
Simply put, all naming operations are relative to a context, so to use JNDI to access a naming service, we need to create an InitialContext object first. As the name implies the InitialContext class encapsulates the initial (root) context that provides the starting point for naming operations.
In simple words, the root context acts as an entry point. Without it, JNDI can’t bind or lookup our resources.
3. How to Test a JNDI Datasource with Spring
Spring provides out-of-box integration with JNDI through SimpleNamingContextBuilder. This helper class offers a great way to mock a JNDI environment for testing purposes.
So, let’s see how we can use the SimpleNamingContextBuilder class to unit test a JNDI datasource.
First, we need to build an initial naming context for binding and retrieving the datasource object:
@BeforeEach
public void init() throws Exception {
SimpleNamingContextBuilder.emptyActivatedContextBuilder();
this.initContext = new InitialContext();
}
We’ve created the root context using the emptyActivatedContextBuilder() method because it provides more flexibility over the constructor, as it creates a new builder or returns the existing one.
Now that we have a context, let’s implement a unit test to see how to store and retrieve a JDBC DataSource object using JNDI:
@Test
public void whenMockJndiDataSource_thenReturnJndiDataSource() throws Exception {
this.initContext.bind("java:comp/env/jdbc/datasource",
new DriverManagerDataSource("jdbc:h2:mem:testdb"));
DataSource ds = (DataSource) this.initContext.lookup("java:comp/env/jdbc/datasource");
assertNotNull(ds.getConnection());
}
As we can see, we use the bind() method to map our JDBC DataSource object to the name java:comp/env/jdbc/datasource.
Then we use the lookup() method to retrieve a DataSource reference from our JNDI context using the exact logical name that we used previously to bind the JDBC DataSource object.
Note that, JNDI will simply throw an exception in case the specified object is not found in the context.
It’s worth mentioning that the SimpleNamingContextBuilder class is deprecated since Spring 5.2 in favor of other solutions such as Simple-JNDI.
4. Mock and Test a JNDI Datasource Using Simple-JNDI
Simple-JNDI allows us to bind objects defined in property files to a mocked JNDI environment. It comes with great support for obtaining objects of type javax.sql.DataSource from JNDI outside Java EE containers.
So, let’s see how we can use it. First, we need to add the Simple-JNDI dependency to our pom.xml:
<dependency>
<groupId>com.github.h-thurow</groupId>
<artifactId>simple-jndi</artifactId>
<version>0.23.0</version>
</dependency>
The latest version of Simple-JNDI library can be found on Maven Central.
Next, we’re going to configure Simple-JNDI with all the details it needs to set up a JNDI context. To do so, we need to create a jndi.properties file which needs to be placed on the classpath:
java.naming.factory.initial=org.osjava.sj.SimpleContextFactory
org.osjava.sj.jndi.shared=true
org.osjava.sj.delimiter=.
jndi.syntax.separator=/
org.osjava.sj.space=java:/comp/env
org.osjava.sj.root=src/main/resources/jndi
java.naming.factory.initial specifies the context factory class that will be used to create the initial context.
org.osjava.sj.jndi.shared=true means that all InitialContext objects will share the same memory.
As we can see, we used the org.osjava.sj.space property to define java:/comp/env as the starting point of all JNDI lookups.
The basic idea behind using both org.osjava.sj.delimiter and jndi.syntax.separator properties is to avoid the ENC problem.
org.osjava.sj.root property lets us define the path to where property files are stored. In our case, all the files will be located under the src/main/resources/jndi folder.
So, let’s define a javax.sql.DataSource object inside our datasource.properties file:
ds.type=javax.sql.DataSource
ds.driver=org.h2.Driver
ds.url=jdbc:h2:mem:testdb
ds.user=sa
ds.password=password
Now, let’s create an InitialContext object for our unit test:
@BeforeEach
public void setup() throws Exception {
this.initContext = new InitialContext();
}
Finally, we’ll implement a unit test case to retrieve the DataSource object already defined in the datasource.properties file:
@Test
public void whenMockJndiDataSource_thenReturnJndiDataSource() throws Exception {
String dsString = "org.h2.Driver::::jdbc:h2:mem:testdb::::sa";
Context envContext = (Context) this.initContext.lookup("java:/comp/env");
DataSource ds = (DataSource) envContext.lookup("datasource/ds");
assertEquals(dsString, ds.toString());
}
5. Conclusion
In this tutorial, we explained how to tackle the challenge of testing JNDI outside J2EE containers. We looked at how to test a mock JNDI datasource using the Spring Framework and the Simple-JNDI library.
As always, the code is available over on GitHub.
