Chapter 3. Logging

Chapter 3. Logging
Prev	Part 3. Reference Guide	Next

Table of Contents

1. Logging Channels

2. OpenJPA Logging

3. Disabling Logging

4. Log4J

5. Apache Commons Logging

5.1. JDK 1.4 java.util.logging

6. Custom Log

Logging is an important means of gaining insight into your application's runtime behavior. OpenJPA provides a flexible logging system that integrates with many existing runtime systems, such as application servers and servlet runners.

There are four built-in logging plugins: a default logging framework that covers most needs, a Log4J delegate, an Apache Commons Logging delegate, and a no-op implementation for disabling logging.

Warning

Logging can have a negative impact on performance. Disable verbose logging (such as logging of SQL statements) before running any performance tests. It is advisable to limit or disable logging for a production system. You can disable logging altogether by setting the openjpa.Log property to none.

1. Logging Channels

Logging is done over a number of logging channels, each of which has a logging level which controls the verbosity of log messages recorded for the channel. OpenJPA uses the following logging channels:

openjpa.Tool: Messages issued by the OpenJPA command line and Ant tools. Most messages are basic statements detailing which classes or files the tools are running on. Detailed output is only available via the logging category the tool belongs to, such as openjpa.Enhance for the enhancer (see Section 2, “ Enhancement ”) or openjpa.MetaData for the mapping tool (see Section 1, “ Forward Mapping ”). This logging category is provided so that you can get a general idea of what a tool is doing without having to manipulate logging settings that might also affect runtime behavior.
openjpa.Enhance: Messages pertaining to enhancement and runtime class generation.
openjpa.MetaData: Details about the generation of metadata and object-relational mappings.
openjpa.Runtime: General OpenJPA runtime messages.
openjpa.Query: Messages about queries. Query strings and any parameter values, if applicable, will be logged to the TRACE level at execution time. Information about possible performance concerns will be logged to the INFO level.
openjpa.DataCache: Messages from the L2 data cache plugins.
openjpa.jdbc.JDBC: JDBC connection information. General JDBC information will be logged to the TRACE level. Information about possible performance concerns will be logged to the INFO level.
openjpa.jdbc.SQL: This is the most common logging channel to use. Detailed information about the execution of SQL statements will be sent to the TRACE level. It is useful to enable this channel if you are curious about the exact SQL that OpenJPA issues to the datastore.
Note
The SQL issued to the database may contain sensitive information. By default the parameter values used in the prepared statements generated by OpenJPA will not be printed in the SQL log - instead you will see a ? for each value. The actual values may be printed by adding PrintParameters=True to the openjpa.ConnectionFactoryProperties property. Also see Using the OpenJPA DataSource

When using the built-in OpenJPA logging facilities, you can enable SQL logging by adding SQL=TRACE to your openjpa.Log property.
OpenJPA can optionally reformat the logged SQL to make it easier to read. To enable pretty-printing, add PrettyPrint=true to the openjpa.ConnectionFactoryProperties property. You can control how many columns wide the pretty-printed SQL will be with the PrettyPrintLineLength property. The default line length is 60 columns.
While pretty printing makes things easier to read, it can make output harder to process with tools like grep.
Pretty-printing properties configuration might look like so:
```
<property name="openjpa.Log" value="SQL=TRACE"/>
<property name="openjpa.ConnectionFactoryProperties" 
    value="PrettyPrint=true, PrettyPrintLineLength=72"/>
```
openjpa.jdbc.Schema: Details about operations on the database schema.