There’s no single definition of IoC, but a central concept is Dependency Injection. From Wikipedia:

Spring, the lightweight container, assumes responsibility for wiring together a set of components, and injects dependencies either via JavaBean properties or constructor arguments. Using Spring you develop a series of simple pieces, and then you tell Spring how to wire them together to create a larger system. This comes in very handy if your architecture relies on reusable “components.” In this chapter, our Data Access Objects (DAOs) are implemented as components (or beans) in a Spring Application Context and our example classes depend on these components as bean properties. If we wanted to reuse our DAOs in another system such as a command-line utility or a web application, those systems would depend on the same components as bean properties, and Spring would take responsibility for wiring our components together based on an XML description of our program’s construction.

Spring encourages reusability by taking on the responsibility of gluing together a set of focused components. Your DAOs don’t care what they are connected to or what components are using them; they are focused solely on providing an interface to whatever component depends on them. If you are interested in a longer description of both Dependency Injection and Inversion of Control, you should read Martin Fowler’s Inversion of Control Containers and the Dependency Injection Pattern.

Now that you know what Spring is all about, let’s get back to Hibernate. This chapter focuses on the DAO pattern, transaction abstractions, and helpers provided by the Spring Framework.

What can you expect from this chapter? While using Spring with Hibernate is straightforward, there are a few steps we need to take before we can really take advantage of Spring’s Hibernate integration. First, because Spring is an IoC container, we need to modify the examples from the previous chapters and create objects to “wire together.” We’ll be exploring the DAO pattern in the next section. After we’ve created one, we will modify our current set of examples to implement a common interface Test to which we will apply a Transactional annotation. Then we will create a Spring application context by writing an XML document which tells Spring what objects to create and what objects to wire together. Finally, we will write a command-line program that loads our Spring application context and starts an example program.

To use Spring in the example project, we’ll need to add another dependency to the build. Open up build.xml and add the dependency highlighted in bold in Example 13-1.

<artifact:dependencies pathId="dependency.class.path">
  <dependency groupId="hsqldb" artifactId="hsqldb" version="1.8.0.7"/>
  <dependency groupId="org.hibernate" artifactId="hibernate" version="3.2.4.sp1">
    <exclusion groupId="javax.transaction" artifactId="jta" />
  </dependency>
  <dependency groupId="org.hibernate" artifactId="hibernate-tools" version="3.2.0.
beta9a" />
  <dependency groupId="org.hibernate" artifactId="hibernate-annotations" version="
3.3.0.ga" />
  <dependency groupId="org.hibernate" artifactId="hibernate-commons-annotations" v
ersion="3.3.0.ga" />
  <dependency groupId="org.apache.geronimo.specs" artifactId="geronimo-jta_1.1_spe
c" version="1.1" />
  <dependency groupId="log4j" artifactId="log4j" version="1.2.14" />
  <dependency groupId="org.springframework" artifactId="spring" version="2.5"/>
</artifact:dependencies>

Great—now when we run the Ant build, we’re going to notice that the Maven Ant task will download spring-2.5.jar from one of the Maven repositories.

I’m always surprised when an author writes a twenty page description of the DAO pattern, its advantages, and its disadvantages. If you read the Sun J2EE blueprint, you’ll read a thick document explaining DAO creation patterns using factories and how the DAO pattern fits into the larger approach to enterprise application development. We’re going to skip much of the formality and just sum up the DAO pattern in two simple bullet points. The DAO pattern:

Or, if you are looking for an even more compact definition: “DAOs hide all the gory details of persistence behind an interface.”

When you use an Object/Relational Mapping (ORM) framework such as Hibernate, you are usually approaching the database as a set of objects. The examples in this book revolve around three objects: Artist, Album, and Track, and the DAO objects we are going to create mirror these three objects: ArtistDAO, AlbumDAO, and TrackDAO. Figure 13-1 shows a class diagram of the ArtistDAO we will be creating shortly.

Figure 13-1. Isolating application and persistence code with a Data Access Object

In this diagram, your application’s logic is represented as the class YourClass. YourClass would have a reference to an ArtistDAO interface which provides four simple methods:

While YourClass is coded to the ArtistDAO interface, you are really invoking an implementation of the ArtistDAO interface—ArtistHibernateDAO. This implementation of ArtistDAO extends Spring’s HibernateDaoSupport class which contains all the necessary magic to make writing Hibernate code as painless as possible. Using this HibernateDaoSupport, you can avoid writing all of the exception handling, transaction management, and session management code that you’ve seen in the previous chapters. In fact, I think you’ll be surprised (and maybe a bit disappointed) at how easy it is to Hibernate in Spring.

There are a few reasons, but first and foremost is increased flexibility. Since you are coding to an interface, you can easily swap in a new implementation if you need to use a different O/R mapping service or storage medium. In the introduction I mentioned that Spring provides an integration layer that can work with any number of object-relational mapping technologies, from iBatis SQL Maps to Oracle’s TopLink to Hibernate, but Spring also provides a rich set of abstractions that make executing SQL with JDBC straightforward. In most of the applications with which I’ve worked, Hibernate provided most of the persistence logic, but it didn’t solve every problem. There are times when you need to execute SQL directly, and Spring provides classes like JDBCTemplate to make this very easy. When you put a DAO interface between your application’s logic and the persistence layer, you’ve made it easier to swap in other implementations for a particular DAO class or method when the need arises.

This flexibility and isolation goes both ways—it is easier to replace both the implementation of a specific DAO class, and it is easier to reuse your persistence layer when you need to rewrite or upgrade your application logic. Take a situation many readers of this book find themselves in right now: your team has been maintaining a legacy system written in Struts 1.x, and you want to upgrade the application to Stripes or Struts 2. If the persistence code is tightly coupled to the web framework code, you will likely find it impossible to rewrite one without rewriting the other.

Following the DAO pattern might seem unnecessary for a simple application, but more often than not, you have a need to reuse persistence code across multiple projects. Creating a set of DAO objects might seem contrary to the agile orthodoxy, but it is an investment in complexity that tends to pay off over time. If your system is anything more than a simple “Hello World” example, you’ll probably want to take some time to separate your persistence logic from your application.

Without delay, let’s jump into writing the code for this example. The first thing we need to do is write the ArtistDAO interface. Create an interface in the com.oreilly.hh.dao package named ArtistDAO and put the code shown in Example 13-2 in this new interface.

package com.oreilly.hh.dao;

import com.oreilly.hh.data.Artist;

/**
 * Provides persistence operations for the Artist object
 */
public interface ArtistDAO {

    /**
     * Persist an Artist instance (create or update)
     * depending on the value of the id
     */
    public Artist persist(Artist artist);

    /**
     * Remove an Artist from the database
     */
    public void delete(Artist artist);

    /**
     * Return an Artist that matches the name argument
     */
    public Artist uniqueByName(String name);

    /**
     * Returns the matching Artist object.   If the 
     * create parameter is true, this method will
     * insert a new Artist and return the newly created
     * Artist object.
     */
    public Artist getArtist(String name, boolean create);
}

All right, that was relatively easy; all we’re talking about here is a few simple methods to implement. Let’s take a look at how we implement this logic using the HibernateDaoSupport class.

The next step is to write an implementation for the ArtistDAO. We are going to write an ArtistHibernateDAO which implements the ArtistDAO interface and extends Spring’s HibernateDaoSupport class. HibernateDaoSupport provides access to your Hibernate Session object and it also provides access to a HibernateTemplate which can be used to simplify almost any operation you can accomplish with the Hibernate Session object. To implement ArtistDAO, create a new class in the com.oreilly.hh.dao.hibernate package to contain the Hibernate-specific implementation of ArtistDAO shown in Example 13-3.

package com.oreilly.hh.dao.hibernate;

import java.util.HashSet;

import org.apache.log4j.Logger;
import org.hibernate.Query;
import org.springframework.orm.hibernate3.support.HibernateDaoSupport;

import com.oreilly.hh.dao.ArtistDAO;
import com.oreilly.hh.data.Artist;
import com.oreilly.hh.data.Track;

/**
 * Hibernate-specific implementation of the ArtistDAO interface. This class
 * extends the Spring-specific HibernateDaoSupport to provide access to 
 * the SessionFactory and the HibernateTemplate.
 */
public class ArtistHibernateDAO extends HibernateDaoSupport 
                                implements ArtistDAO {

  private static Logger log = 
    Logger.getLogger(ArtistHibernateDAO.class);
    
  /* (non-Javadoc)
   * @see com.oreilly.hh.dao.ArtistDAO#persist(com.oreilly.hh.data.Artist)
   */
  public Artist persist(Artist artist) { 
    return (Artist) getHibernateTemplate().merge(artist);
  }
    
  /* (non-Javadoc)
   * @see com.oreilly.hh.dao.ArtistDAO#delete(com.oreilly.hh.data.Artist)
   */
  public void delete(Artist artist) { 
    getHibernateTemplate().delete(artist);
  }

  /* (non-Javadoc)
   * @see com.oreilly.hh.dao.ArtistDAO#uniqueByName(java.lang.String)
   */
  public Artist uniqueByName(final String name) { 
    return (Artist) getHibernateTemplate().execute(new HibernateCallback() {
      public Object doInHibernate(Session session) {
        Query query = getSession().getNamedQuery("com.oreilly.hh.artistByName");
        query.setString("name", name);
        return (Artist) query.uniqueResult();
      }
    });
  }
  
  /* (non-Javadoc)
   * @see com.oreilly.hh.dao.ArtistDAO#getArtist(java.lang.String, boolean)
   */
  public Artist getArtist(String name, boolean create) { 
    Artist found = uniqueByName( name );
    if (found == null && create) {
      found = new Artist(name, new HashSet<Track>(), null);
      found = persist(found);
    }
    if (found != null && found.getActualArtist() != null) {
      return found.getActualArtist();
    }
    return found;
  }
}

HibernateDaoSupport gives us a hook to the SessionFactory without having to know anything about how the Hibernate environment was created or configured. When we subclass HibernateDaoSupport our class then has access to a Hibernate Session via getSession() and a HibernateTemplate via getHibernateTemplate(). You already know what you can do with a Hibernate Session object (that’s why you read the previous 10 chapters). The interesting bits of the Spring/Hibernate integration are supplied by the HibernateTemplate class. Let’s delve into the details of this class.

To quote from the JavaDoc for HibernateTemplate: “This class can be considered [an] alternative to working with the raw Hibernate 3 Session API.” HibernateTemplate simplifies tasks that would otherwise be accomplished using the Session object, and it also translates HibernateExceptions to more general DataAccessExceptions. You use HibernateTemplate in one of two ways: you can call a set of simple helper functions such as load(), save(), delete(), or you can execute a HibernateCallback instance using the execute() method. The most common way you’ll find yourself using HibernateTemplate is through the simple helper functions—you only need to create a HibernateCallback object when you want to execute some Hibernate-specific code within the HibernateTemplate.

What is a DataAccessException? When we introduced the DAO pattern, it was an attempt to shield application code from the specifics of any one persistence API or library. It wouldn’t help us if our technology-neutral DAO threw a Hibernate-specific ObjectNotFoundException, so HibernateTemplate is responsible for handling any Hibernate-specific exceptions which may occure inside it. The Stripes API provides a simple way to tolerate such implementation-specific exceptions by wrapping them in its own generalized data access exceptions.

HibernateTemplate and HibernateCallback are the real workhorses that will help us avoid writing lines and lines of unnecessary Java code. Let’s use them both to reimplement the examples from the previous chapters.

Before we use HibernateTemplate and HibernateCallback we need to run through a quick survey of the methods available to us.

HibernateTemplate provides a number of simple convenience methods that can turn multiple lines of direct Hibernate Session API code into simple one-liners. Let’s take a look at some examples of convenience methods to simplify querying a database table. Example 13-4 shows some examples of querying and finding objects.

HibernateTemplate tmpl = getHibernateTemplate();

// All of these lines Find Artist with name 'Pavement'
List artists = tmpl.find("from com.oreilly.hh.data.Artist a " +
                         "  where a.name = 'Pavement'"); 

String name = "Pavement";
List artists = tmpl.find("from com.oreilly.hh.data.Artist a " +
                         "  where a.name = ?", name); 

List artists = tmpl.findByNamedParam("from com.oreilly.hh.data.Artist a " +
                                     "  where a.name = :name", "name", name); 

// Assuming that there is a NamedQuery annotation "Artist.byName" on the 
// Artist class
List artists = tmpl.findByNamedQuery("Artist.byName", name); 

Artist artist = new Artist();
artist.setName("Pavement");
List artists = tmpl.findByExample(artist); 

// If we want to iterate through the result
Iterator artists = tmpl.iterate("from com.oreilly.hh.data.Artist " +
                                "  where a.name = ?", name); 

// The following lines find all Artists
List artists = tmpl.find("from com.oreilly.hh.data.Artist"); 
List artists = tmpl.loadAll(Artist.class);

The find methods are relatively straightforward:

If we already know the value of the ID for a particular persistent object, HibernateTemplate provides helper methods for loading an object by an ID, as shown in Example 13-5.

// Identifier of Artist to load
Integer id = 1;

// Load an Artist object, return persistent Artist object
Artist artist = getHibernateTemplate().load(Artist.class, id);

// Populate the object passed in as a parameter.  Using the 
// object's type to specify the class
Artist artist = new Artist();
getHibernateTemplate().load(artist, id);

In the first example, we call the load() function with a Class and a Serializable ID value. Hibernate will then retrieve the row from the database and return an instance of the requested object. Instead of a Class object, you can also pass an object instance, Hibernate will use the type of the parameter to determine the class to retrieve.

We’ve examined the helpers on HibernateTemplate for querying and the helpers for loading. What about modifying rows in the database? Example 13-6 shows some examples that insert or update rows in the database.

// Persist a new instance in the database
Artist a  = new Artist();
a.setName("Fischerspooner");
getHibernateTemplate().save(a);

// Load, modify, update a row in the database
Artist a = getHibernateTemplate().load(Artist.class, 1);
a.setName("Milli Vanilli");
getHibernateTemplate().update(a);

// Either insert or update depending on the identifier 
// of the object; associate resulting object with Session
Artist a = getHibernateTemplate().merge(a);

save() and update() are straightforward; both of these methods correspond to the similarly named methods on the Hibernate Session object. save() generates a new ID and inserts a new row in the table, and update() updates the matching row in the table. merge() is a bit more flexible: it examines the id of the parameter and calls either save() or update() depending on whether the ID is null.

You can also execute any arbitrary code that uses a Hibernate Session with a HibernateCallback. Before I try to explain exactly what this means, let’s take a look at Example 13-7.

final String name = "Pavement";

Artist artist = (Artist) getHibernateTemplate().execute(new HibernateCallback() {
  public Object doInHibernate(Session session) {
    Criteria criteria = session.createCriteria(Artist.class);
    criteria.add(Restrictions.like("name", name));
    return criteria.uniqueResult();
  }
});

So what exactly is happening here? This example instantiates an anonymous inner class, which implements the HibernateCallback interface and passes it to the execute() method in HibernateTemplate. The HibernateCallback interface defines a single method doInHibernate(), which is executed with a Hibernate Session. The body of this method (as implemented in our anonymous inner class) uses the Hibernate Criteria API to generate a query that retrieves an Artist by name.

Why would we use the callback method when we could have easily obtained a reference to the Hibernate Session and created the same Criteria object? Even though we can access the Session object directly in HibernateDaoSupport using the getSession() method, we want to avoid direct calls to the Hibernate API because we don’t want to throw any Hibernate-specific exceptions (not even a RuntimeException). Remember your application is accessing this DAO via an interface, and it doesn’t know or care about the Hibernate-specific ObjectNotFoundException or about an exception in your HQL. Instead of accessing the Session object directly with getSession(), you can and should shield the rest of your application from such gory plumbing details by using a HibernateCallback to run any Hibernate API calls within the HibernateTemplate.

Because they’re all very similar, it’s not worth wasting paper listing and talking about the others. You wouldn’t want to type in all that code anyway, so download the code examples if you’d like to look at them.

Taking a closer look at the hibernateProperties in Example 13-8, you will notice that there are a number of interesting configuration properties. Let’s examine each of them:

Later in this chapter, we’ll write a class named TestRunner which knows how to retrieve a bean from a Spring ApplicationContext, which is expected to implement the Test interface, and execute that bean’s run() method. The beans it uses will be adaptations of the CreateTest, QueryTest, and AlbumTest classes from the previous chapters. To work in this new way, we’ll have them each implement a common interface called Test, shown in Example 13-9.

package com.oreilly.hh;
import org.springframework.transaction.annotation.Transactional;

/**
 * A common interface for our example classes.  We'll need this
 * because TestHarness needs to cast CreateTest, QueryTest, or 
 * AlbumTest to a common interface after it retrieves the bean
 * from the Spring application context.
 */
public interface Test {
    /**
     * Runs a simple example
     */
    @Transactional(readOnly=false)
    public void run();
}

This Test interface serves as a common interface for use by TestRunner, and it also gives us a convenient method to annotate with the Transactional annotation. The Transactional annotation takes care of binding a Session to the current Thread, starting a transaction, and either committing the transaction if the method returns normally, or rolling it back if there is an exception.

For more information about the @Transactional annotation, please see Appendix D.

To turn on the processing of the Transactional annotation, we used this chunk of configuration in our applicationContext.xml:

  <!-- enable the configuration of transactional behavior based on annotations -->
  <tx:annotation-driven transaction-manager="transactionManager"/> 
  <bean id="transactionManager"
        class="org.springframework.orm.hibernate3.HibernateTransactionManager">
    <property name="sessionFactory">
      <ref local="sessionFactory"/>
    </property>
  </bean>

The tx:annotation-driven element simply activates the Transactional annotation and points it to a PlatformTransactionManager. HibernateTransactionManager is an implementation of the Spring Framework’s PlatformTransactionManager. It takes care of binding a Hibernate Session from the sessionFactory to the current Thread using SessionFactoryUtils. Since our DAO objects all extend HibernateDaoSupport and use the HibernateTemplate, these persistent objects are able to participate in transactions and obtain the same thread-bound Session object. This isn’t just useful for dealing with transactions, it is essential when we’re working with lazy associations.

The Transactional annotation ensures that the same Session will remain open and bound to the current Thread during the execution of the annotated method. Without this annotation, Hibernate would create a new Session for every operation that needed a Session, and you would be unable to fetch any associations of the objects you had retrieved using Hibernate.

Why is this? Let’s back track a bit to topics we brought up in Chapter 5. Recall that in Hibernate 3, associations between mapped objects default to lazy loading. Unless you change this explicitly for a particular class or association, related objects are not retrieved from the database until you’ve traversed to a particular object. For example, if you retrieve an Album object from the database, the List of AlbumTrack objects is not retrieved until you call the album.getAlbumTracks() method. To accomplish this, Hibernate does two things:

Fetching lazy associations only works if the PersistentSet is referencing an active Session. Without an open session, attempting to traverse a lazy association will throw an exception. In a web application, you might use something like Spring’s OpenSessionInViewFilter to make sure you have a reference to a Session throughout a single request. In this application, we’re relying on the Transactional annotation to make sure that all of the code in any run() method implementation has access to the same Hibernate Session object.

Now that we’ve got our Test interface defined and set up to provide a stable transaction environment to its implementations, we can revise CreateTest, QueryTest, and AlbumTest. First is the adaptation of CreateTest shown in Example 13-10.

package com.oreilly.hh;

import java.sql.Time;
import java.util.*;
import com.oreilly.hh.dao.*;
import com.oreilly.hh.data.*;

/**
 * Create sample data, letting Hibernate persist it for us.
 */
public class CreateTest implements Test {

    private ArtistDAO artistDAO;
    private TrackDAO trackDAO;

    /**
     * Utility method to associate an artist with a track
     */
    private static void addTrackArtist(Track track, Artist artist) {
        track.getArtists().add(artist);
    }

    /* (non-Javadoc)
     * @see com.oreilly.hh.Test#run()
     */
    public void run() {
        StereoVolume fullVolume = new StereoVolume();

        Track track = new Track("Russian Trance", "vol2/album610/track02.mp3",
                Time.valueOf("00:03:30"), new HashSet<Artist>(), new Date(),
                fullVolume, SourceMedia.CD, new HashSet<String>());
        addTrackArtist(track, artistDAO.getArtist("PPK", true));
        trackDAO.persist(track);
    }

    public ArtistDAO getArtistDAO() { return artistDAO; }
    public void setArtistDAO(ArtistDAO artistDAO) {
        this.artistDAO = artistDAO;
    }

    public TrackDAO getTrackDAO() { return trackDAO; }
    public void setTrackDAO(TrackDAO trackDAO) {
        this.trackDAO = trackDAO;
    }
}

Notice that CreateTest has two private member variables, artistDAO and trackDAO, both of which are made visible with accessor methods as bean properties. Then we have a simple run() method, as mandated by the Test interface, which in this case creates an instance of Track, associates an Artist with the Track, and then persists the Track object with a call to trackDAO.makePersistent(). That’s it—no try/catch/finally blocks and no mention of a transaction. We’ve offloaded almost everything to the Spring framework with the help of our DAO. Example 13-11 is an excerpt from applicationContext.xml in which an instance of this CreateTest class is created as a bean with the ID createTest, and the bean properties artistDAO and trackDAO are populated with references to the DAO beans.

<bean id="createTest" class="com.oreilly.hh.CreateTest"> 
  <property name="trackDAO" ref="trackDAO"/>
  <property name="artistDAO" ref="artistDAO"/>
</bean>

Compare this implementation of CreateTest to the original version in Example 3-3. You can hardly compare them. The non-Spring version of CreateTest had to take care of Session creation, transaction management, exception handling, and configuration. The new version doesn’t even mention the Session object. In fact, there’s nothing Hibernate-specific in this latest CreateTest: the DAOs prevent our application logic from having to deal directly with the underlying persistence mechanism. In other words, once you get your mind around the Spring Framework and get it set up, it is an order of magnitude easier than working with Hibernate directly. See Example 13-12.

package com.oreilly.hh;

import java.sql.Time;
import java.util.List;
import org.apache.log4j.Logger;
import com.oreilly.hh.dao.TrackDAO;
import com.oreilly.hh.data.Track;

/**
 * Retrieve data as objects
 */
public class QueryTest implements Test {

    private static Logger log = Logger.getLogger(QueryTest.class);

    private TrackDAO trackDAO;

    public void run() {
        // Print the tracks that will fit in five minutes
        List<Track> tracks = trackDAO.tracksNoLongerThan(
          Time.valueOf("00:05:00")); 
        for (Track track : tracks) {
            // For each track returned, print out the 
            // title and the playTime
            log.info("Track: "" + track.getTitle() + "", "
                    + track.getPlayTime());
        }
    }

    public TrackDAO getTrackDAO() { return trackDAO; }
    public void setTrackDAO(TrackDAO trackDAO) {
        this.trackDAO = trackDAO;
    }
}

The reimplementation of QueryTest also defines a private member variable referencing the TrackDAO object, and the run() method invokes the method trackDAO.tracksNoLongerThan(), passing it a Java.sql.Time instance of 5 minutes. This code then loops through the results and prints out the Track’s title and playTime properties using Log4J. See Example 13-13.

package com.oreilly.hh;

import java.sql.Time;
import java.util.*;
import org.apache.log4j.Logger;
import com.oreilly.hh.dao.*;
import com.oreilly.hh.data.*;

/**
 * Create sample album data, letting Hibernate persist it for us.
 */
public class AlbumTest implements Test {

  private static Logger log = Logger.getLogger( AlbumTest.class );
    
  private AlbumDAO albumDAO; 
  private ArtistDAO artistDAO;
  private TrackDAO trackDAO;
    
  public void run() {
    // Retrieve (or create) an Artist matching this name
    Artist artist = artistDAO.getArtist("Martin L. Gore", true); 

    // Create an instance of album, add the artist and persist it 
    // to the database.
    Album album = new Album("Counterfeit e.p.", 1,
      new HashSet<Artist>(), new HashSet<String>(),
      new ArrayList<AlbumTrack>(5), new Date());
    album.getArtists().add(artist);
    album = albumDAO.persist(album); 

    // Add two album tracks
    addAlbumTrack(album, "Compulsion", "vol1/album83/track01.mp3",
                  Time.valueOf("00:05:29"), artist, 1, 1);
    addAlbumTrack(album, "In a Manner of Speaking",
                  "vol1/album83/track02.mp3", Time.valueOf("00:04:21"),
                          artist, 1, 2);

    // persist the album
    album = albumDAO.persist( album ); 

    log.info(album);
  }

  /**
   * Quick and dirty helper method to handle repetitive portion of creating
   * album tracks. A real implementation would have much more flexibility.
   */
  private void addAlbumTrack(Album album, String title, String file,
                             Time length, Artist artist, int disc,
                             int positionOnDisc) {
    // Create a new Track object and add the artist
    Track track = new Track(title, file, length, new HashSet<Artist>(),
                            new Date(), new StereoVolume(), SourceMedia.CD,
                            new HashSet<String>());
    track.getArtists().add(artist);

    // Persist the track to the database
    track = trackDAO.persist(track);

    // Add a new instance of  AlbumTrack with the persisted 
    // album and track objects
    album.getTracks().add(new AlbumTrack(track, disc, positionOnDisc));
  }

  public AlbumDAO getAlbumDAO() { return albumDAO; }
  public void setAlbumDAO(AlbumDAO albumDAO) {
    this.albumDAO = albumDAO;
  }

  public ArtistDAO getArtistDAO() { return artistDAO; }
  public void setArtistDAO(ArtistDAO artistDAO) {
    this.artistDAO = artistDAO;
  }

  public TrackDAO getTrackDAO() { return trackDAO; }
  public void setTrackDAO(TrackDAO trackDAO) {
    this.trackDAO = trackDAO;
  }
}

AlbumTest is more complex than either CreateTest or QueryTest because it deals with the creation and persistence of multiple objects and the side-effects of cascading. Let’s step through the code:

That’s the extent of our Test implementations. The general recipe here was to migrate all of the persistence code to our DAOs and then to migrate our standalone CreateTest, QueryTest, and AlbumTest classes to beans with properties referencing these DAOs, with the actual test code moved into a run() method as required by the Test interface. This lets the Spring Framework wire all of our components together. In the next section we’ll see how all of this is executed.

All this code is useless if we don’t have a way of loading a Spring ApplicationContext and executing our Test objects. For this, we’ll create a TestRunner class with a static main() method to be executed from our Ant build.xml. Example 13-14 is a complete listing of TestRunner. This class takes care of loading our Spring ApplicationContext, retrieving a Test implementation, and executing it.

package com.oreilly.hh;

import org.apache.log4j.Logger;
import org.apache.log4j.PropertyConfigurator;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

/**
 * A simple harness to run our tests.  Configures Log4J,
 * creates an ApplicationContext, retrieves a bean from Spring
 */
public class TestRunner {

  private static Logger log;
    
  public static void main(String[] args) throws Exception {
    // Configure Log4J from a properties file
    PropertyConfigurator.configure(
      TestRunner.class.getResource("/log4j.properties")); 
    log = Logger.getLogger(TestRunner.class);
        
    // Load our Spring Application Context
    log.info( "Initializing TestRunner..." );
    log.info( "Loading Spring Configuration..." );
    ApplicationContext context = 
      new ClassPathXmlApplicationContext("applicationContext.xml");

    // Retrieve the test name from the command line and 
    // run the test.
    String testName = args[0];
    log.info( "Running test: " + testName );
    Test test = (Test) context.getBean(testName); 
    test.run();
  }
}

TestRunner takes care of three things for us, as noted in the JavaDoc:

To run TestRunner and retrieve the appropriate bean from our Spring ApplicationContext, we need to modify our Ant build.xml script. Find the targets named ctest, qtest, and atest, and change them to contain the following XML, as shown in Example 13-15.

<target name="atest" description="Creates and persists some album data" depends=
"compile">
  <java classname="com.oreilly.hh.TestRunner" fork="true">
    <classpath refid="project.class.path" />
    <arg value="albumTest"/>
  </java>
</target>

<target name="ctest" description="Creates and persists some sample data"
        depends="compile">
  <java classname="com.oreilly.hh.TestRunner" fork="true" failonerror="true">
    <classpath refid="project.class.path" />
    <arg value="createTest"/>
  </java>
</target>

<target name="qtest" description="Runs a query" depends="compile">
  <java classname="com.oreilly.hh.TestRunner" fork="true">
    <classpath refid="project.class.path" />
    <arg value="queryTest"/>
  </java>
</target>

The TestRunner class uses its first command-line argument as the name of the bean to retrieve from the Spring ApplicationContext. In the build.xml we are invoking TestRunner and passing in the name of the bean (from applicationContext.xml) as an argument.

To create the test database, run ant schema as usual, and to insert data into the database, run our new version of ant ctest:

% ant schema
% ant ctest
Buildfile: build.xml

prepare:

compile:

ctest:
     [java]  INFO TestRunner:20 - Initializing TestRunner...
     [java]  INFO TestRunner:21 - Loading Spring Configuration...
     [java]  INFO TestRunner:25 - Running test: createTest

BUILD SUCCESSFUL
Total time: 3 seconds

Run ant qtest to invoke the new QueryTest example and confirm that everything we put together worked as expected:

% ant qtest
Buildfile: build.xml

prepare:

compile:

qtest:
     [java]  INFO TestRunner:20 - Initializing TestRunner...
     [java]  INFO TestRunner:21 - Loading Spring Configuration...
     [java]  INFO TestRunner:25 - Running test: queryTest
     [java]  INFO QueryTest:25 - Track: "Russian Trance", 00:03:30
     [java]  INFO QueryTest:25 - Track: "Video Killed the Radio Star", 00:03:49
     [java]  INFO QueryTest:25 - Track: "Test Tone 1", 00:00:10

BUILD SUCCESSFUL
Total time: 3 seconds

Finally, we can run the new AlbumTest example. Type ant atest, and you should see the following output:

% ant atest
Buildfile: build.xml

prepare:

compile:

atest:
     [java]  INFO TestRunner:16 - Initializing TestRunner...
     [java]  INFO TestRunner:17 - Loading Spring Configuration...
     [java]  INFO TestRunner:21 - Running test: albumTest
     [java]  INFO AlbumTest:40 - Persisted Album: 1
     [java]  INFO AlbumTest:59 - Saved an album named Counterfeit e.p.
     [java]  INFO AlbumTest:60 - With 2 tracks.

BUILD SUCCESSFUL
Total time: 2 seconds

The Spring Framework and Hibernate complement each other quite nicely, and if you are about to adopt Hibernate for a large application, you should consider basing your application on the Spring Framework. Once you’ve invested the time to learn the framework, we’re certain you’ll find yourself writing less transaction handling, connection management, and Hibernate session management code. The less time you have to spend on these tasks, the more time you can devote to your application’s specific requirements and logic. Portability is another reason to use Spring (or any IoC container, for that matter) and to start using patterns like the DAO. While Hibernate is the first choice among persistence libraries today, there’s no telling what the next decade will bring. If you isolate your Hibernate-specific code from the rest of your application, it’ll be that much easier to experiment with the next technology that comes down the road.

Take care not to be deceived by the simplicity of Hibernate when coupled with Spring. The authors of this book unanimously agreed that while Hibernate was a great thing, it can sometimes be difficult to debug and diagnose for any number of reasons: a single-character typo, a badly mapped table, a slightly incorrect flush mode, or some arcane incompatibility with a JDBC driver. Spring makes Hibernate easy because it provides some useful abstractions—you gain simplicity, but it takes you that much further away from executing a SQL statement against a database. While you might not have to write your own transaction handling code, there will be times when these abstractions can make it more difficult to diagnose the root cause of an error. Don’t get me wrong—I would not use Hibernate without Spring, but you’ll be better able to diagnose problems is you have a solid grounding in the details of Hibernate.

In the next chapter, we’ll show you how to take the next step—how to integrate Hibernate into a web application framework called Stripes. In this web application, you’ll see how Spring serves as a neutral broker between Stripes and Hibernate. As you read that chapter, you should keep in mind the fact that most of the popular web application frameworks in use today have some facility for direct integration with Spring. If you use Struts 2, Wicket, or Spring MVC, many of the concepts remain the same. Spring is something of a Rosetta Stone for software, and once you adopt it you have access to all the libraries which were designed to interoperate with Spring. Use Spring as your foundation, and you’ll have an easier time swapping in different technologies as your requirements change. Among some of the possibilities are writing DAO components in JRuby or Groovy instead of Java, integrating a cron-like facility using Quartz, and exposing service objects as SOAP endpoints using libraries like Apache CXF.