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.
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]](img/warning.gif) | 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  | 
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
				behavior.
				
				
				kodo.Configuration: Messages issued
				by the configuration framework.
				
				
				kodo.Enhance: Messages pertaining to
				enhancement and runtime class generation.
				
				
				kodo.MetaData: Details about the generation 
				of metadata and object-relational mappings.
				
				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 INFO level.
				
				
				kodo.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.
				
				
				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 SQL=TRACE to
				your kodo.Log property.
				
				Kodo can optionally reformat the logged SQL to
				make it easier to read. To enable pretty-printing,
				add PrettyPrint=true to the
				
				kodo.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:
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
				
				kodo.jdbc.Schema: Details about operations 
				on the database schema.
				
				
				kodo.Profile: Information related to Kodo's 
				profiling framework.
				
|    |