Chapter 3. Configuration

This would allow you to rename the SQL LOWER function.

3.4.6. Hibernate statistics

If you enable hibernate.generate_statistics, Hibernate exposes a number of metrics that are useful when tuning a running system via SessionFactory.getStatistics(). Hibernate can even be configured to expose these statistics via JMX. Read the Javadoc of the interfaces in org.hibernate.stats for more information.

3.5. Logging

Hibernate utilizes Simple Logging Facade for Java [http://www.slf4j.org/] (SLF4J) in order to log various system events. SLF4J can direct your logging output to several logging frameworks (NOP, Simple, log4j version 1.2, JDK 1.4 logging, JCL or logback) depending on your chosen binding. In order to setup logging you will need slf4j-api.jar in your classpath together with the jar file for your preferred binding - slf4j-log4j12.jar in the case of Log4J. See the SLF4J documentation

[http://www.slf4j.org/manual.html] for more detail. To use Log4j you will also need to place a log4j.properties file in your classpath. An example properties file is distributed with Hibernate in the src/ directory.

It is recommended that you familiarize yourself with Hibernate's log messages. A lot of work has been put into making the Hibernate log as detailed as possible, without making it unreadable. It is an essential troubleshooting device. The most interesting log categories are the following:

Table 3.9. Hibernate Log Categories

org.hibernate.transactionLog transaction related activity

org.hibernate.jdbc Log all JDBC resource acquisition

org.hibernate.hql.ast.ASTLog HQL and SQL ASTs during query parsing

When developing applications with Hibernate, you should almost always work with debug enabled for the category org.hibernate.SQL, or, alternatively, the property hibernate.show_sql enabled.

44

Implementing a NamingStrategy

3.6. Implementing a NamingStrategy

The interface org.hibernate.cfg.NamingStrategy allows you to specify a "naming standard" for database objects and schema elements.

You can provide rules for automatically generating database identifiers from Java identifiers or for processing "logical" column and table names given in the mapping file into "physical" table and column names. This feature helps reduce the verbosity of the mapping document, eliminating repetitive noise (TBL_ prefixes, for example). The default strategy used by Hibernate is quite minimal.

You can specify a different strategy by calling Configuration.setNamingStrategy() before adding mappings:

SessionFactory sf = new Configuration()

.setNamingStrategy(ImprovedNamingStrategy.INSTANCE)

.addFile("Item.hbm.xml")

.addFile("Bid.hbm.xml")

.buildSessionFactory();

org.hibernate.cfg.ImprovedNamingStrategy is a built-in strategy that might be a useful

starting point for some applications.

3.7. Implementing a PersisterClassProvider

You can configure the persister implementation used to persist your entities and collections:

•by default, Hibernate uses persisters that make sense in a relational model and follow Java Persistence's specification

•you can define a PersisterClassProvider implementation that provides the persister class used of a given entity or collection

•finally, you can override them on a per entity and collection basis in the mapping using

@Persister or its XML equivalent

The latter in the list the higher in priority.

You can pass the PersisterClassProvider instance to the Configuration object.

SessionFactory sf = new Configuration()

.setPersisterClassProvider(customPersisterClassProvider)

.addAnnotatedClass(Order.class)

.buildSessionFactory();

45

Chapter 3. Configuration

The persister class provider methods, when returning a non null persister class, override the default Hibernate persisters. The entity name or the collection role are passed to the methods. It is a nice way to centralize the overriding logic of the persisters instead of spreading them on each entity or collection mapping.

3.8. XML configuration file

An alternative approach to configuration is to specify a full configuration in a file named hibernate.cfg.xml. This file can be used as a replacement for the hibernate.properties file or, if both are present, to override properties.

The XML configuration file is by default expected to be in the root of your CLASSPATH. Here is an example:

<?xml version='1.0' encoding='utf-8'?>

<!DOCTYPE hibernate-configuration PUBLIC

"-//Hibernate/Hibernate Configuration DTD//EN" "http://www.hibernate.org/dtd/hibernate-configuration-3.0.dtd">

<hibernate-configuration>

<!-- a SessionFactory instance listed as /jndi/name --> <session-factory

name="java:hibernate/SessionFactory">

<!-- properties -->

<property name="connection.datasource">java:/comp/env/jdbc/MyDB</property> <property name="dialect">org.hibernate.dialect.MySQLDialect</property> <property name="show_sql">false</property>

<property name="transaction.factory_class"> org.hibernate.transaction.JTATransactionFactory

</property>

<property name="jta.UserTransaction">java:comp/UserTransaction</property>

<!-- mapping files -->

<mapping resource="org/hibernate/auction/Item.hbm.xml"/> <mapping resource="org/hibernate/auction/Bid.hbm.xml"/>

<!-- cache settings -->

<class-cache class="org.hibernate.auction.Item" usage="read-write"/> <class-cache class="org.hibernate.auction.Bid" usage="read-only"/>

<collection-cache collection="org.hibernate.auction.Item.bids" usage="read-write"/>

</session-factory>

</hibernate-configuration>

The advantage of this approach is the externalization of the mapping file names to configuration. The hibernate.cfg.xml is also more convenient once you have to tune the Hibernate cache. It is your choice to use either hibernate.properties or hibernate.cfg.xml. Both are equivalent, except for the above mentioned benefits of using the XML syntax.

46