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="jdbc:oracle:thin:@booksvr.org:1521:BOOKS"/>
       <property name="userName" value="scott"/>
       <property name="password" value="tiger"/>
    </bean>

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"/>
    </bean>

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"/>
    </bean>

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="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"/>
    <tx:annotation-driven/>

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

Testing
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.