Focusing on open APIs for enterprise applications

Open Web Magazine

Subscribe to Open Web Magazine: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Open Web Magazine: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Open Web Authors: Jayaram Krishnaswamy, Bob Gourley, Kevin Benedict, Pat Romanski, Newswire

Related Topics: Java EE Journal, Apache Web Server Journal, Java Developer Magazine, Open Web Magazine

J2EE Journal: Article

Java Feature — Using the Java Persistence API (JPA) with Spring 2.0

How to use JPA in new or existing Spring applications to achieve standardized persistence

We extend Spring's AbstractJpaTests superclass, which is a subclass of JUnit TestCase, and then we specify the test fixture and configuration location. The test fixture will be automatically dependency-injected if we provide a setter method. We can provide any number of setter methods, but it's usually good practice to test one thing at a time. We must implement the getConfigLocations() method to return an array of the Spring configurations we want to load. Note that most of the configuration data is identical to that used in a deployed scenario, minimizing the amount of additional work needed to implement tests:

package org.bookguru;

import org.springframework.test.jpa.AbstractJpaTests;

public class BookInventorySystemTest extends AbstractJpaTests {

    private BookInventorySystem bookInventorySystem;

    public void setBookInventorySystem(
       BookInventorySystem bookInventorySystem) {
       this.bookInventorySystem = bookInventorySystem;

    protected String[] getConfigLocations() {
       return new String[] {"/my/path/my-spring-config.xml"};

Now we can add any number of test methods. These can access data by using our data access object (DAO) fixture or the jdbcTemplate and sharedEntityManager instance variables inherited from JpaTestCase as follows:

   public void testAddBook() {
     int oldBookCount = jdbcTemplate.queryForInt("SELECT COUNT(0) FROM BOOK");
     bookInventorySystem.addBook(12769356, "War and Peace", "Leo Tolstoy", Genre.FICTION);
     int newBookCount = jdbcTemplate.queryForInt("SELECT COUNT(0) FROM BOOK");
     assertEquals("Must have added new row in BOOK table",oldBookCount + 1, newBookCount);

Here we're using JDBC queries in the same transaction to verify the correct behavior of our DAO. First we query for the number of rows in the BOOK table. Then we add a book, being sure to flush the current unit of work, using the EntityManager.flush() method. This forces the persistence provider to issue the necessary SQL update. Now we can issue another JDBC query to verify that we added an additional row. We know that our DAO doesn't merely execute without exception, but also causes the appropriate changes in our database. Those changes will be rolled back when the testAddBook() method has completed, so the changes won't be persisted or affect other tests.

With this approach, we can very quickly validate our O-R mappings and queries, as well as our Spring configuration. Very quick round trips mean that we can rapidly iterate as we enrich and map our domain model, identifying any problems early so that they take minimal time to rectify.

Best Practices
As we see from the example, most of the effort to develop JPA in Spring is in the initial configuration setup. Once we get the application context settled, the rest is just a matter of simple programming as we add more classes and beans. When working with multiple Spring/JPA projects it helps to have a template XML file that can be copied and modified as needed. If a specific architecture and pattern is commonly used, it may make sense to have a JPA-specific bean definition file and just file-include it in the application context file for every project. (Note that Spring allows a configuration to be split into any number of XML files.)

In the past, each persistence implementation had a different session API, and using a Spring template/DAO was helpful because it let Spring manage session-level resources and insulate the program from the vendor API. JPA is a standard API, so there's no longer a need to do this kind of shielding. In Spring 2.0 the entity managers are managed for you, so although Spring supports the same kind of DAO templates for JPA, they're no longer as necessary.

Spring DAOs also provide exception translation by mapping the various platform and database exceptions into a consistent Spring exception hierarchy. This provides the application with a normalized, unified exception-handling scheme, regardless of the particular database sitting underneath. In Spring 2.0 this facility is made available through the @Repository annotation, without requiring the use of DAO/template objects. Because there's currently no standard way for database exceptions to be wrapped in a JPA PersistenceException, this annotation will help applications process persistence exceptions and map them to specific causes. It's also particularly valuable for existing Spring applications that will migrate from proprietary data access APIs to JPA, or for mixing JPA and JDBC use in the same application. As in any Spring application, using Spring with JPA ensures a consistent and testable programming model, whether you're deploying to a Java EE application server, a Web container such as Tomcat, or a standalone application.

In this article we've shown how to use JPA in new or existing Spring applications to achieve standardized persistence, with little effort or change in coding style. New Spring users can begin writing applications and bring their JPA experience with them. The flexibility and loose coupling that Spring offers, with the standardization of JPA persistence, provides developers with the best of both worlds and gives them a platform that's easy to develop on and convenient to test.

The JPA Reference Implementation can be downloaded from, and Spring 2.0 can be downloaded from To learn more about using JPA with Spring, see the Spring JPA documentation at

• Mike Keith and Merrick Schincariol. Pro EJB 3: Java Persistence API. Apress, 2006.
• Rob Harrob and Jan Machacek. Pro Spring. Apress, 2005.
• Rod Johnson, Juergen Hoeller, Alef Arendsen, Thomas Risberg, Colin Sampaleanu. Professional Java Development with the Spring Framework. Wrox, 2005.
• Rod Johnson, Juergen Hoeller, Alef Arendsen, Colin Sampaleanu, Rob Harrop, Thomas Risberg, Darren Davison, Dmitriy Kopylenko, Mark Pollack, Thierry Templier, Erwin Vervaet, Portia Tung, Ben Hale, Adrian Colyer, John Lewis, Costin Leau, Rick Evans, Spring Framework 2.02 Reference Documentation. 2007.

More Stories By Mike Keith

Mike Keith has more than 15 years of teaching, research and practical experience in object-oriented and distributed systems, specializing in object persistence. He was the co-specification lead for EJB 3.0 (JSR 220), a member of the Java EE 5 expert group (JSR 244) and co-authored the premier JPA reference book Pro EJB 3: Java Persistence API. Mike is currently a persistence architect for Oracle and a popular speaker at numerous conferences and events around the world.

More Stories By Rod Johnson

Rod Johnson is the senior vice president of the Application Platform Division at VMware with more than 12 years of technology and management experience. Founder of the Spring Framework, he continues to guide the direction of Spring and is a member of the Java Community Process Executive Committee.

Comments (2) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
GIUSEPPE SCHIAVO 11/09/07 05:04:51 PM EST

Very disappointing. I though Rod Johnson would have done much better than this.
There is no link to download a working example plus there is at least one error. The bean definition below, which is included in the article, violates the schema definition because the attribute class cannot be defined in a property element. :(

Rob Bygrave 04/29/07 06:56:41 AM EDT

In regards this point:
The Java Persistence API was architected so it could be used both inside and outside a Java EE 5 container. When there's no container to manage JPA entity managers and transactions, the application must bear more of the management burden.
Is there any plan to have JPA provide a "Stateless" or "Sessionless" architecture - where there would be no requirement to manage EntityManager's?

(and would make using JPA outside a container much simpler)