Dec 11, 2009

Simplifying JPA Testing with Spring’s PersistenceUnitPostProcessor

At my current client, we are writing an application that is deployed as an ear into Websphere. One of the goals of the project is to write out-of-container tests so that we don’t have to build and deploy over and over again. Two of the tools we are using in this application is JPA for the ORM and Spring. Initially, we had two persistance.xml files, one for production and one for testing. Some of the differences were that the production version used a transaction type of JTA and the test version used resource local. There were a few other property differences, but otherwise they needed to be identical. At first this was ok, but as our list of classes and properties grew it became a maintenance hassle.

At this point we wanted to find a way to only have one persistance.xml to use in both prod and testing. After some research we found Spring’s PersistenceUnitPostProcessor interface. Implementing this interface allows you to make changes to the persistence unit that is defined in persistence.xml. There is one method that looks like this:

public void postProcessPersistenceUnitInfo(MutablePersistenceUnitInfo pui);

The MutablePersistenceUnitInfo object that is passed in has all the information in persistence.xml in it and can be altered as needed. Here’s how we got it to work. Here’s how our production perstence.xml looks:

<?xml version="1.0"?>
<persistence xmlns="" version="1.0"
   <persistence-unit name="oracleOpenJpa" transaction-type="JTA">


         <property name="openjpa.ConnectionFactoryMode" value="managed" />
         <property name="openjpa.TransactionMode" value="managed" />


Here is our implementation of the interface:

package org.acme.jpa;

import java.util.Map;
import java.util.Properties;

import javax.persistence.spi.PersistenceUnitTransactionType;
import javax.sql.DataSource;

import org.apache.commons.lang.ObjectUtils;
import org.springframework.orm.jpa.persistenceunit.MutablePersistenceUnitInfo;
import org.springframework.orm.jpa.persistenceunit.PersistenceUnitPostProcessor;

public class MyPersistenceUnitPostProcessor implements PersistenceUnitPostProcessor {

   private String persistenceUnitName;
   private Properties persistenceProperties;
   private DataSource dataSource;

   public MyPersistenceUnitPostProcessor(final String persistenceUnitName, 
          final DataSource dataSource, final Properties persistenceProperties) {
      this.persistenceUnitName = persistenceUnitName;
      this.persistenceProperties = persistenceProperties;
      this.dataSource = dataSource;

   public void postProcessPersistenceUnitInfo(final MutablePersistenceUnitInfo pui) {
      if(ObjectUtils.equals(persistenceUnitName, pui.getPersistenceUnitName())) {

         final Properties properties = pui.getProperties();

         for (final Map.Entry entries : persistenceProperties.entrySet()) {
            properties.put(entries.getKey(), entries.getValue());


And here’s the spring configuration:

<bean id="entityManagerFactory" 
   <property name="persistenceUnitName" value="oracleOpenJpa" />
   <property name="dataSource" ref="oracleDataSource" />
   <property name="persistenceUnitPostProcessors">
         <bean class="org.acme.jpa.MyPersistenceUnitPostProcessor">
            <constructor-arg value="oracleOpenJpa" />
            <constructor-arg ref="oracleDataSource" />
                  <prop key="openjpa.ConnectionFactoryMode">local</prop>
                  <prop key="openjpa.TransactionMode">local</prop>

As you can see in the implementation, we set the JTA datasource to null (we don’t use it for testing), and set the non-jta datasource to the one defined in Spring. We also set the transaction type to resource local, set the provider class name and add whatever properties we pass in. In our case we just set a couple properties to “local”. By using these tools, we are able to just keep one persistance.xml file for both production and for testing and the maintenance hassle is gone.

About the Author

Object Partners profile.
Leave a Reply

Your email address will not be published. Required fields are marked *

Related Blog Posts
Modern Development Environment for C++: Part 2
In Part 1 of this series, I gave a quick overview of each tool in the development environment and how I came to the conclusion that the tool was a good fit. Today I’m going […]
Mock Intl and Date globals in Jest
In Javascript land, mocking the browser global objects can be a bit of a pain for tests. Searching StackOverflow gives plenty of complicated answers. Some suggesting using 3rd party mock libraries. Some that overwrite the […]
Bitbucket Parameterized Pipelines
Introduction I’d like to address how to handle lots of deployment environments withinBitBucket Pipelines. Below I’m presenting two options: Using tags to parameterize builds Using the BitBucket API to pass variables Lots of Environments There […]
AWS Cloud HSM, Docker and NGINX
There is quite a bit of easily searchable content on the security benefits of leveraging a Hardware Security Module to manage cryptographic keys, so I will leave that to the scope of another article. The […]