Logging is an important means of gaining insight into your application's runtime behavior. Kodo provides a flexible logging system that integrates with many existing runtime systems, such as application servers and servlet runners.
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
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. Kodo uses the following logging channels:
kodo.Tool: Messages issued by the Kodo
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
kodo.Enhance for the enhancer
(see Section 5.2, “Enhancement”) or
kodo.MetaData for the mapping tool
(see Section 7.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
kodo.Runtime: General Kodo runtime messages.
kodo.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
kodo.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 Kodo
issues to the datastore.
When using the built-in Kodo logging facilities, you can
enable SQL logging by adding
Kodo can optionally reformat the logged SQL to
make it easier to read. To enable pretty-printing,
PrettyPrint=true to the
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:
JPA XML format:
<property name="kodo.Log" value="SQL=TRACE"/> <property name="kodo.ConnectionFactoryProperties" value="MaxActive=100, PrettyPrint=true, PrettyPrintLineLength=72"/>
JDO properties format:
kodo.Log: SQL=TRACE kodo.ConnectionFactoryProperties: MaxActive=100, PrettyPrint=true, PrettyPrintLineLength=72