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: Jnan Dash, Jayaram Krishnaswamy, Bob Gourley, Kevin Benedict, Pat Romanski

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

The persistence unit name is just the name of the persistence unit, and the data source is defined in the usual way. Spring always uses one or more Java 2 Standard Edition (J2SE) data source definitions as the starting point for persistence configuration. A number of data source types are available, but in this case we're using a simple pooled JDBC data source defined as follows:

    <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource">
       <property name="driverClassName" value="oracle.jdbc.OracleDriver"/>
       <property name="url" value=""/>
       <property name="userName" value="scott"/>
       <property name="password" value="tiger"/>

The loadTimeWeaver property specifies the weaving strategy that Spring uses to implement the container provider SPI and provides the weaving capability. In this example we use the instrumentation feature introduced in the Java SE 5 VM (specified on the jre command line) so we specify the InstrumentationLoadTimeWeaver class. If we were running in a Tomcat server, we would set this to ReflectiveLoadTimeWeaver and use the Tomcat class loader provided by Spring. If we were running Spring inside the Oracle Containers for J2EE (OC4J) server, we would set it to OC4JLoadTimeWeaver, which plugs into the special class-loading support in OC4J.

Configuring the Vendor Adapter
A keen observer might have noticed that we snuck an additional fourth dependency into the entity manager factory bean and wired it to a bean called vendorAdapter. The jpaVendorAdapter property is an optional property that facilitates setting vendor-specific properties that are common across providers. These properties detail:

  • Whether the SQL traces should be logged
  • The database platform that's being used
  • Whether the schema should be generated in the database when the application starts
We added this property because the various persistence providers tend to provide a mechanism for configuring these properties, but the mechanisms differ from provider to provider. By defining common property names in Spring, the settings can be specified regardless of the provider implementation being wired in underneath. This facilitates switching between different persistence providers by minimizing configuration changes - something that can help users determine which of the available providers exhibits the best performance or can best meet their application requirements.

The following is the definition of the vendorAdapter bean that we wired to the jpaVendorAdapter property. It defines TopLink as the vendor and gives values to the three common property settings.

    <bean id="vendorAdapter" class="org.springframework.orm.jpa.vendor.TopLinkJpaVendorAdapter">
       <property name="databasePlatform" value="${platform}"/>
       <property name="showSql" value="true"/>
       <property name="generateDdl" value="true"/>

The databasePlatform string is understood by the persistence provider so even though the property name is common, the values may be different across vendors. We have assigned it the variable platform and defined it in an external application context properties file. (See Professional Java Development with the Spring Framework for a description of how to define and use properties files.).

Implementations such as TopLink define many more JPA settings that can be used to configure the provider in ways ranging from specifying what kind of cache to use to declaring custom classes and mapping types. These additional properties are typically defined as properties in the persistence.xml file.

Other Configurations
The next thing we need to do is declare the BookInventorySystem class as a Spring bean. The simple bean definition merely points out that Spring should proxy and manage instances of the class as they are created.

    <bean class="org.bookguru.BookInventorySystem"/>

Next, we'll use the local resource-level transactions provided by the JPA entity manager, so we define the transaction manager bean and bind it to the JpaTransactionManager class. We then refer its entity manager factory dependency to our entity manager factory bean.

    <bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
       <property name="entityManagerFactory" ref="entityManagerFactory"/>

This transaction manager is designed to support transactional connections through JPA but it will also allow direct JDBC access using Spring's JDBC abstraction library.

We need to do a bit of housekeeping to indicate to Spring that it should honor and act on any @PersistenceContext and @Transactional annotations found in bean classes. This is done by adding the following two simple elements:

    <bean class=""/>

The tx namespace and schema should be added to the top of the application context XML file so the namespace can be recognized.

Spring is designed to facilitate agile development practices - particularly to make testing much easier than in traditional Java EE development. The use of dependency injection and POJO programming makes unit testing much easier in general, but Spring doesn't stop there.

Spring provides a powerful integration test facility that lets code that accesses persistent data be tested without deploying to an application server or any container other than Spring. This functionality is packaged in the spring-mock.jar file included in the Spring distribution and provides the following services:

  • Automatic transaction demarcation. Each test runs in its own transaction, which is rolled back by default. This ensures that each test can run in its own sandbox without producing side effects.
  • Caching configurations. A configuration such as the O-R mappings is loaded only once, ensuring that start-up costs aren't repeated for each and every test.
  • Dependency injection of test cases. Test cases can be injected just like application components, making them easier to develop and initialize.
Taken together, these services mean that tests can be written quickly and easily, and executed in seconds. The following example shows how easily we can test our book inventory system.

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)

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.