Hibernate configuration and startup

The regular way of initializing Hibernate is to build a SessionFactory object from a Configuration object. If you like, you can think of the Configuration as an object representation of a configuration file (or a properties file) for Hibernate.
Let’s look at some variations before we wrap it up in the HibernateUtil class.

Building a SessionFactory
This is an example of a typical Hibernate startup procedure, in one line of code, using automatic configuration file detection:

SessionFactory sessionFactory = new Configuration().configure().buildSessionFactory();

Wait—how did Hibernate know where the configuration file was located and which one to load?
When new Configuration() is called, Hibernate searches for a file named hibernate.properties in the root of the classpath. If it’s found, all hibernate.* properties are loaded and added to the Configuration object.
When configure() is called, Hibernate searches for a file named hibernate.cfg.xml in the root of the classpath, and an exception is thrown if it can’tbe found. You don’t have to call this method if you don’t have this configuration file, of course. If settings in the XML configuration file are duplicates of properties set earlier, the XML settings override the previous ones.
The location of the hibernate.properties configuration file is always the root of the classpath, outside of any package. If you wish to use a different file or to have Hibernate look in a subdirectory of your classpath for the XML configuration file, you must pass a path as an argument of the configure() method:

SessionFactory sessionFactory = new Configuration()
.configure("/persistence/auction.cfg.xml").buildSessionFactory();

Finally, you can always set additional configuration options or mapping file locations on the Configuration object programmatically,  
before building the SessionFactory:

SessionFactory sessionFactory = new Configuration()
.configure("/persistence/auction.cfg.xml")
.setProperty(Environment.DEFAULT_SCHEMA, "CAVEATEMPTOR")
.addResource("auction/CreditCard.hbm.xml")
.buildSessionFactory();

Many sources for the configuration are applied here: First the hibernate.properties file in your classpath is read (if present). Next, all settings from /persistence/auction.cfg.xml are added and override any previously applied settings. Finally, anadditional configuration property (a default database schema name) is set programmatically, and an additional Hibernate XML mapping metadata file is addedto the configuration.

You can, of course, set all options programmatically, or switch between different XML configuration files for different deployment databases. There is effectively no limitation on how you can configure and deploy Hibernate; in the end, you only need to build a SessionFactory from a prepared configuration.

NOTE Method chaining—Method chaining is a programming style supported by many Hibernate interfaces. This style is more popular in Smalltalk than in Java and is considered by some people to be less readable and more difficult to debug than the more accepted Java style. However, it’s convenient in many cases, such as for the configuration snippets you’ve seen in this section. Here is how it works: Most Java developers declare setter or adder methods to be of type void, meaning they return no value; but in Smalltalk, which has no void type, setter or adder methods usually return
the receiving object. We use this Smalltalk style in some code examples,
but if you don’t like it, you don’t need to use it. If you do use this coding style, it’s better to write each method invocation on a different line. Otherwise, it may be difficult to step through the code in your debugger.